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Abstract 


In  the  proofs-as-programs  methodology,  verified  programs  are  developed  through  theorem-proving 
in  a  constructive  logic.  Under  this  approach,  the  theorem- proving  process  can  be  regarded  as 
a  program  derivation  process.  The  merits  of  this  approach  to  programming  are  twofold.  First, 
working  with  proofs  instead  of  programs  concentrates  the  developer’s  effort  on  the  intellectually 
difficult  part  of  the  development  process:  understanding,  solving,  and  explaining  the  solution  to  a 
mathematical  problem.  Second,  the  proof  provides  a  formal  and  trustworthy  basis  for  an  explana¬ 
tion  of  the  program.  This  thesis  investigates  the  use  of  proof  transformations  as  a  way  to  address 
important  concerns  in  program  derivation  that  are  not  addressed  by  theorem-proving  alone. 

One  difficulty  with  the  proofs-as-programs  strategy  arises  from  the  conflict  between  elegance 
and  efficiency.  A  simple,  elegant  proof  may  lead  to  an  inefficient  program.  A  more  complex  proof 
that  corresponds  to  a  more  efficient  program  may  be  difficult  to  invent  or  understand.  With 
proof  transformations,  a  developer  can  start  with  an  elegant  proof  that  is  easy  to  understand,  and 
incrementally  derive  a  more  complex  proof  and  thus  a  more  efficient  program.  Another  problem 
comes  from  the  need  for  adaptation  and  reuse.  With  current  automated  support  for  theorem¬ 
proving,  it  is  difficult  to  re-use  previous  work  other  than  by  re-using  lemmas  from  a  library.  This 
kind  of  reuse  is  analogous  to  the  use  of  subroutine  libraries  in  ordinary  programming,  and  does  not 
directly  support  adaptation.  Proof  transformations  provide  a  way  of  adapting  a  proof  to  a  new 
context. 

One  standard  approach  to  metaprogramming  tasks  like  proof  transformation  has  been  to  use  a 
separate  programming  language,  such  as  ML,  as  a  metalanguage  for  a  type  theory  considered  as  an 
object  logic.  A  more  recently  developed  strategy,  which  has  been  applied  to  programming  language 
semantics,  theorem-proving,  and  related  problems,  is  the  use  of  a  higher-order  logic  programming 
language  as  a  logical  framework.  This  thesis  adopts  the  second  approach,  using  the  Elf  programming 
language,  which  gives  a  logic  programming  interpretation  to  the  Edinburgh  Logical  Framework. 
We  show  a  partially  verified  implementation  of  support  for  the  proofs-as-programs  strategy  and 
proof  transformations,  and  argue  that  the  implementation  techniques  contribute  to  the  concise, 
declarative,  and  verifiable  implementation  of  metaprogramming  tasks  for  formal  logic.  Through 
case  studies  of  small  programming  problems,  we  demonstrate  that  known  program  transformations 
can  be  implemented  in  the  domain  of  proofs,  and  expressed  as  derived  logical  rules.  The  case  studies 
supply  evidence  that  a  development  methodology  based  on  proof  transformation  can  provide  a  useful 
integration  between  the  flexibility  of  program  transformation  and  the  formal  connection  between  a 
program  and  its  specification  of  the  proofs-as-programs  methodology. 
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Chapter  1 


Introduction 


Research  in  constructive  logics  and  type  theories  has  resulted  in  a  good  understanding  of  the 
relation  of  formal  constructive  proof  to  computation,  and  has  produced  a  number  of  systems  (e.g., 
Nuprl  [C+86],  the  Calculus  of  Constructions  [DFH+91],  Alf  [Mag92],  LEGO  [LPT89j,  PX  [Hay90]) 
capable  of  supporting  the  development  of  programs  by  constructive  theorem-proving  (the  proofs-as- 
programs  strategy).  There  are  now  a  number  of  researchers  experimenting  with  the  methodology, 
but  there  are  many  problems  that  have  to  be  solved  before  it  will  achieve  applicability  to  practical 
software  development. 

This  thesis  continues  a  line  of  research  that  began  with  the  observation  of  Goad  [Goa80]  that  a 
formal  proof  contains  information  that  is  not  essential  for  computation,  but  that  “is  useful  in  the 
transformation  of  computing  methods;”  his  work  exploits  this  information  to  transform  proofs  in 
order  to  specialize  algorithms  to  their  inputs.  Pfenning  [Pfe90]  generalizes  this  line  of  thought  and 
argues  that  proof  transformation  can  be  used  to  address  two  problems  with  the  pure  proofs-cis- 
programs  methodology.  The  first  problem  is  the  trade-off  between  elegance  and  efficiency,  which 
exists  in  the  domain  of  proofs  for  much  the  same  reasons  that  it  exists  in  the  domain  of  programs. 
The  second  is  the  need  to  adapt  programs  to  changing  specifications.  A  change  to  a  specification 
imposes  a  need  to  change  the  associated  proof;  although  theorem  proving  tools  (proof  editors, 
automated  provers,  etc.)  can  support  this  process  to  some  extent,  there  are  many  difficulties  that 
result  in  duplication  of  effort.  In  this  thesis  we  investigate  some  ways  to  address  these  problems  by 
proof  transformation,  using  the  Elf  language  [Pfe91a]  to  implement  a  small  constructive  logic  and 
functional  programming  language,  the  extraction  of  programs  from  proofs,  and  transformations  on 
proofs.  We  carry  out  several  case  studies  of  program  development  showing  the  application  of  these 
techniques. 

In  this  introduction  we  describe  the  conceptual  basis  for  the  research.  Section  1.1  gives  a  brief 
introduction  to  the  proofs-as-programs  strategy.  Section  1.2  discusses  the  use  of  a  type  theory  as  a 
logical  framework.  Then  we  discuss  proof  transformations  and  give  a  small  example  adapted  from 
Goad.  Finally  we  make  some  general  remarks  about  the  aims,  methods,  and  contributions  of  oui 
work,  discuss  some  related  research,  and  describe  the  organization  of  the  body  of  the  thesis. 


1 


2 


1.1  Proofs  as  programs 

The  development  of  verified  programs  through  theorem-proving  in  a  type  theory  or  constructive 
logic  has  been  explored  by  many  researchers,  e.g.,  [C+86],  [CH85],  [Hay90],  [MW81],  [ML80], 
[€■*■86],  [CH85],  [Hay90].  Although  various  systems  have  been  used  to  formalize  this  proofs-as- 
programs  strategy,  the  basic  idea  is  the  same:  to  rely  on  a  realizability  interpretation  of  constructive 
logic  in  order  to  obtain  a  program  from  a  proof.  A  verified  program  is  obtained  by  the  following 
process;  write  a  specification  for  the  program  as  a  theorem  in  the  language  of  a  formal  deductive 
system,  prove  the  theorem  in  a  constructive  way,  and  finally  extract  a  term  in  a  functional  pro¬ 
gramming  language  from  the  proof.  Usually  the  specification  has  the  form  Va: :  r .  3i/ :  r' .  P{x,  y); 
then  the  extracted  term  has  the  type  r  — ►  r',  and  it  is  a  function  that,  given  an  x  of  type  r, 
computes  a  y  of  type  r'  such  that  P(x,y)  holds. 

A  simple  example,  presented  informally,  is  the  following  proof  for  an  algorithm  to  compute  an 
upper  bound  of  both  the  sum  and  product  of  two  rational  numbers.  The  example  is  adapted  from 
Goad  [Goa80]. 

The  specification  is  the  theorem  to  be  proved,  which  says  that,  given  two  rational  numbers  x 
and  y,  an  upper  bound  for  their  sum  and  product  exists. 

Specification  1.1  'ix  .'iy  .3z  .{z  >  x  +  y)  A  {z  >  xy) 

The  proof  of  the  theorem  is  a  very  simple  case  analysis. 

Proof  1.2  There  are  two  cases: 

Case  X  <  1.  Then  let  2  =  ?/  -I- 1,  since  (j/-f-l>x-|-y)  A  (y+l>  xy). 

Case  X  >  1.  There  are  two  subcases: 

Case  y  <  1.  Then  let  2  =  x  -|-  1,  since  (x-|-l>x-|-y)  A  (x-t-l>  xy). 

Case  y  >  1.  Let  z  =  2xy,  since  (2xy  >  x  -|-  y)  A  (2xy  >  xy). 


□ 

Programs  extracted  from  proofs  closely  follow  the  proof  structure;  here,  the  case  analyses  correspond 
to  conditionals.  For  readability,  we  show  programs  in  ML  rather  than  A-calculus.  One  possible 
realization  for  the  proof  is: 

Program  1.3 

fim  u  X  y  =  if  X  <=  1  then  y+1  else  (if  y  <=  1  then  x+1  else  2*x*y) 


The  virtues  of  this  approach  to  program  development  have  been  described  extensively  elsewhere, 
notably  by  Bates  and  Constable  [BC85].  Briefly,  we  can  say  that  working  with  proofs  instead  of 
programs  concentrates  the  developer’s  effort  on  the  intellectually  difficult  part  of  the  development 
process,  i.e.,  understanding,  solving,  and  explaining  the  solution  to  a  mathematical  problem.  To  the 
extent  that  the  proof  process  and  program  extraction  can  be  trusted,  the  program  so  developed  is 
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guaranteed  to  be  a  correct  implementation  of  the  formal  specification.  With  an  automated  system 
to  aid  in  the  manipulation  of  proofs,  the  developer  has  significant  help  in  carrying  out  this  part 
of  the  development  process,  and  the  proof  provides  a  formal  basis  for  the  documentation  of  the 
program. 

In  what  sense  does  Program  1.3  give  the  computational  content  of  Proof  1.2?  Section  2.3 
gives  a  precise  description  of  our  working  notion  of  the  computational  content  of  a  proof,  but  to 
set  the  stage,  this  section  gives  an  intuitive  explanation  based  on  a  constructive  interpretation  of 
logical  operations,  which  originated  with  Heyting  [Hey34].  Formal  systems  for  defining  realizability 
conform  to  this  interpretation. 

The  interpretation  relies  on  an  informal  notion  of  “construction”.  For  an  initial  understand¬ 
ing,  it  is  enough  to  take  this  to  mean  a  function  definable  in  a  suitable  programming  language. 
(Constructions  as  terms  in  a  typed  lambda  calculus  -  the  Curry-Howard  isomorphism  -  are  de¬ 
scribed  in  [How69].)  Then  the  following  describes  what  it  means  to  constructively  prove  a  logically 
compound  statement  (this  is  adapted  from  [TvD88]); 

•  A  proof  of  A  A  5  is  given  by  presenting  a  proof  of  A  and  a  proof  of  B. 

•  A  proof  of  A  V  5  is  given  by  presenting  either  a  proof  of  A  or  a  proof  c'  B. 

•  A  proof  of  A  D  .B  is  a  construction  that  when  given  any  proof  of  A  produces  a  proof  of  B. 

•  There  is  no  proof  of  L  (absurdity,  contradiction). 

•  A  proof  of  A  is  a  construction  that  when  given  any  proof  of  A  produces  a  proof  of  1. 

•  A  proof  of  Vx  .  A(x)  is  a  construction  that  when  given  a  term  i  produces  a  proof  of  A(t). 

•  A  proof  of  3x  .  A(x)  is  a  witness  t  and  a  proof  of  A{t). 

This  description  gives  a  direct  intuitive  basis  for  the  rules  of  Gentzen’s  (intuitionistic)  natural 
deduction  [Gen69],  in  the  sense  that  it  is  evident  how  to  compute  a  proof  in  the  above  sense  for 
the  conclusion  of  each  rule,  given  constructive  proofs  for  the  premises.  For  example,  the  rule  of 
implication  introduction  says  that,  given  a  proof  of  B  under  the  assumption  A,  we  can  conclude 
AdB: 

-P 

A 


But  a  given  proof  of  B  under  the  assumption  A  is  a  construction  that  transforms  a  proof  of  A  into 
a  proof  of  B,  so  it  is  also  a  proof  of  A  D  B  on  the  above  interpretation.  The  rule  of  implication 
elimination  says  that,  given  a  proof  of  A  D  B  and  a  proof  of  A,  we  can  conclude  B: 

AdB  a 

- DE 

B 

According  to  the  interpretation,  we  have  a  construction  that  transforms  any  proof  of  A  into  a  proof 
of  B.  Then  a  proof  of  B  can  be  obtained  by  applying  this  construction  to  the  given  proof  of  A. 
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Now  it  should  be  possible  to  see  how  Program  1.3  represents  the  computational  content  of 
Proof  1.2.  The  end-formula  of  the  proof  is  Va: .  Vy .  32: .  {2:  >  i  -|-  j/)  A  (2  >  xy).  The  program  defines 
a  function  of  two  arguments,  which  correspond  to  the  two  universally  quantified  variables  of  the 
formula.  It  returns  a  value  that  witnesses  the  existential.  Strictly  speaking,  it  should  return  a  pair 
consisting  of  a  value  z  and  a  proof  p  of  (2  >  x+y)  A  (2  >  xy).  Since  p  has  no  computational  interest 
we  have  suppressed  it.  Section  2.3  describes  how  our  implementation  systematically  suppresses  some 
computationally  uninteresting  information  using  modified  realizability. 

The  description  also  gives  a  basis  for  rejecting  the  classical  principle  of  the  excluded  middle,  i.e. 
A  V  -lA  for  any  A.  If  the  principle  is  accepted,  the  interpretation  implies  that  we  have  either  a 
proof  of  A  or  a  proof  of  -lA,  i.e.,  every  proposition  is  decidable.  From  an  operational  point  of  view, 
it  is  also  useful  to  consider  the  equivalent  law  of  indirect  proof,  or  proof  by  contradiction: 

- p 

^A 


—  L/pP 
A 

If  this  were  acceptable,  then  in  particular  we  could  construct  a  proof  of  the  form 

- p 

->3x .  A{x) 


- L/pP 

3x .  A(x) 

But  a  constructive  interpretation  of  the  premise  is  a  construction  that  transforms  a  proof  of 
-i3a: .  A(a:)  to  a  proof  of  ±.  This  does  not  give  any  way  in  general  to  compute  a  witness  for 
the  conclusion,  that  is,  a  t  such  that  A(t)  is  true. 

So  as  not  to  mislead  the  reader,  it  is  important  to  mention  that  there  are  ways  of  recovering 
computational  content  from  certain  classical  proofs.  Murthy’s  thesis  [Mur90]  describes  how  this 
can  be  done  in  practice  and  explores  the  very  interesting  connection  to  nonlocal  control  operators. 


1.2  Type  theory  as  a  logical  framework 

Constructive  approaches  to  mathematics  go  back  at  least  to  the  work  of  Brouwer  early  in  this  cen¬ 
tury.  The  subtleties  and  implications  of  these  approaches  for  pure  mathematics  have  little  relevance 
to  this  thesis;  useful  historical  sketches  can  be  found  in  [C+86]  and  [TvD88].  The  type  theories 
currently  being  studied  in  computer  science  may  be  said  to  descend  from  the  AUTOMATH  family 
of  languages  [dB80]  for  the  machine  checking  of  mathematics,  and  from  Martin- Lof’s  development 
of  a  formal  theory  for  expressing  the  syntax  and  semantics  of  constructive  mathematics  [ML73]. 

In  current  computer  science  research  there  are  two  main  ways  of  exploiting  type  theory.  One 
is  to  use  it  as  a  formal  representation  of  constructive  logic  to  support,  among  other  activities, 
programming  by  theorem  proving.  Since  type  theory  provides  an  internal  A-calculus  as  well  as  a 
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representation  of  logic,  the  computational  contents  of  a  proof  can  be  internally  represented.  This 
is  the  approach  of  most  work  with  Nuprl  and  the  Calculus  of  Constructions,  and  there  are  type 
theories  (e.g.  PX)  carefully  tailored  for  use  as  programming  languages.  Another  approach,  that 
taken  in  this  thesis,  is  to  use  a  type  theory  as  a  logical  framework  or  metalanguage  for  formally 
representing  a  logic.  LF,  the  Edinburgh  Logical  Framework  [HHP93]  is  a  type  theory  designed 
for  this  purpose.  Our  implementation  of  proof  transformations  uses  the  programming  language 
Elf  [Pfe91a],  which  gives  an  operational  interpretation  to  the  types  of  LF  to  support  a  logic  pro¬ 
gramming  style  of  metaprogramming.  The  framework  approach  permits  a  freer  choice  of  object 
logic  and  programming  language  than  is  possible  when  using  a  type  theory  directly  as  a  logic  and/or 
programming  language,  and  leaves  more  control  in  the  hands  of  the  implementor  (over  reduction, 
for  example).  As  a  consequence,  for  an  object  logic  we  are  able  to  choose  a  pure  logic,  since  the 
framework  provides  a  A-calculus  in  which  to  represent  the  program  extracted  from  a  proof,  and 
we  give  two  different  formulations  of  program  extraction.  However,  this  freedom  and  control  have 
both  an  implementation  cost  and  a  theoretical  cost.  An  implementation  of  a  type  theory  will 
provide  normalization  of  terms  of  that  theory  (which  amounts  to  program  execution)  for  free,  and 
the  metatheory  which  is  worked  out  for  the  type  theory  gives  theorems  for  free  about  the  theory 
regarded  as  a  logic  or  programming  language.  On  the  other  hand,  when  the  type  theory  is  used  as 
a  framework,  the  logic  and  programming  language  being  studied  are  not  the  language  of  the  type 
theory.  The  implementor  must  write  (meta)  programs  to  execute  programs  of  the  language  under 
consideration.  The  metatheory  of  the  framework  is  not  the  metatheory  of  the  logic,  which  must  be 
developed  explicitly. 


1.3  Proof  transformation 


A  proof  transformation,  for  the  purposes  of  this  work,  is  a  procedure  that,  given  a  formal  proof 
X>,  produces  another  formal  proof  V,  where  the  validity  of  V  (along  with  the  correctness  of  the 
transformation)  guarantees  the  validity  of  V,  although  V  and  V  may  not  prove  the  same  theorem. 
The  transformation  tactics  of  Nuprl  [C'''86]  implement  this  idea.  Because  of  the  close  relation 
between  the  structure  of  a  proof  and  the  program  extracted  from  it,  a  transformation  can  be  useful 
for  the  form  of  the  proof  it  produces. 

Proof  transformations  may  depend  on  global  analysis  (as  in  [Mur90]),  requiring  inductive  proofs 
of  correctness.  However,  as  we  show  here,  useful  changes  to  program  structure  may  be  accomplished 
by  uniform  proof  transformations,  i.e,  those  that  depend  only  on  local  syntactic  properties  of  the 
proofs.  As  wiU  become  apparent,  in  a  natural  deduction  setting  they  can  be  thought  of  as  derived 
rules  of  inference.  When  properly  encoded  in  the  Elf  language  they  are  proved  correct  by  type 
checking.  The  simplest  of  these  encoded  transformations  correspond  to  higher-order  patterns  in 
the  sense  of  [Pfe91b].  Though  often  it  is  not  possible  to  code  a  rule  in  this  restricted  form,  the  style 
of  transformation  we  consider  can  still  be  encoded  in  the  form  of  a  single  rewrite  rule  to  obtain 
an  executable  Elf  program,  if  the  application  of  the  rule  is  restricted  so  that  only  ground  terms 
(complete  closed  proofs)  are  supplied  as  input.  Thus  the  encodings  are  related  to  the  work  of  Huet 
and  Lang  [HL78]  on  program  transformations  expressed  as  second-order  patterns,  translated  to  the 
proof  level,  and  to  that  of  Hannan  and  Miller  [HM88]. 
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1.3.1  An  example 

The  following  illustration  of  proof  transformation  applies  Goad’s  pruning  transformation  [GoaSO] 
to  Proof  1.2.  Pruning  is  a  way  of  allowing  for  adaptation  and  reuse  in  the  case  of  the  specialization 
of  a  program  to  fixed  values  for  its  inputs.  Here,  proof  transformation  specializes  the  proof  to 
y  =  .5  by  substituting  the  value  for  the  variable  throughout  the  proof,  normalizing  the  result,  and 
then  pruning. 

Here  is  an  informal  presentation  of  the  new  specification  and  its  proof  after  the  substitution  of 
.5  for  y  and  normalization.  The  case  distinction  on  the  value  of  y  has  been  eliminated. 

Specification  1.4 

Va: .  3z .  (2:  >  X  +  .5)  A  (2  >  (x)(.5)) 

Proof  1.5  There  are  two  cases: 

Case  X  <  1.  Then  let  z  =  1.5,  since  (1.5  >  x  +  .5)  A  (1.5  >  (x)(.5)). 

Case  X  >  1.  Now  .5  <  1;  therefore,  let  2  =  x  +  1,  since  (x  +  1  >  x  +  .5)  A  (x  +  1  >  (x)(.5)). 

□ 

Program  1.6 

(From  Proof  1.5) 

fun  u’  X  =  if  X  <*  1  then  1.5  else  x+1 


This  program  can  be  obtained  from  Program  1.3  by  partial  application  and  reductions  in  the 
A-calculus.  This  seems  to  be  the  best  one  can  hope  for  by  operating  purely  on  the  program 
without  looking  at  the  proof.  But  it  is  evident  from  the  proof  that  the  case  analysis  on  x  is 
unnecessary:  when  y  =  .5,  x  +  1  satisfies  the  specification  regardless  of  the  value  of  x.  Goad’s 
pruning  transformation  provides  a  way  to  capture  this  observation  because  it  transforms  the  proof 
rather  than  the  program,  allowing  us  to  change  the  function  computed,  not  just  specialize  it  to  one 
of  its  inputs,  while  ensuring  that  the  program  satisfies  the  specification. 

The  particular  form  of  pruning  needed  for  this  example  replaces  a  case  analysis  by  one  of  its 
arms  when  the  case  that  holds  for  that  arm  is  not  used.  We  show  the  transformation  as  a  schema 
for  proofs  in  natural  deduction  style. 

Transformation  1.7  Transform 

-P  —P 
A  B 

Vi  2?2 

AW  B  C  C  „ 

- vEP 

(7 
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to 

T>3 

c 

provided  that  B  does  not  appear  as  an  open  assumption  in  V3. 

This  transformation  is  applicable  to  Proof  1.5  because  the  assumption  a:  >  1  is  not  needed  in 
order  to  show  that  (a:  +  1  >  i  +  .5)  A  (a:  +  1  >  (i)(.5)).  The  result  of  the  transformation  is  the 
trivial  proof: 

Proof  1.8  (of  Specification  1.4)  We  pick  z  =  x  -f- 1,  since  (a:  +  1  >  x  +  .5)  A  (x  +  1  >  (x)(.5l)  for 
all  X.  □ 

This  corresponds  to  the  program 

Program  1.9 
fun  u”  X  =  x+1 


Note  that  Program  1.9  and  Program  1.6  compute  different  functions,  although  both  satisfy  Speci¬ 
fication  1.4. 

1.3.2  Proof  transformations  and  program  transformations 

As  the  example  shows,  proof  transformation  shares  many  features  with  program  transformation. 
Some  proof  transformations  merely  translate  program  transformations  into  a  different  domain.  For 
instance,  the  substitution  and  normalization  transformations  that  produce  Proof  1.5  from  Proof  1.2 
correspond  to  simple  program  transformations.  More  significantly,  both  approaches  emphasize  a 
development  process  that  proceeds  by  small,  intellectually  manageable  increments,  and  both  aim 
at  supporting  re-use  of  the  objects  being  developed.  But  the  pruning  operation  demonstrates 
a  major  difference  between  the  two  methodolopes.  A  program  describes  the  functionality  of  a 
computation,  but  not  its  purpose;  by  contrast,  a  proof  describes  both:  the  functionality  is  specified 
by  the  structure  of  the  proof,  and  the  purpose  is  expressed  by  the  theorem  that  is  proved.  This 
added  expressiveness  allows  the  pruning  transformation  to  produce  Program  1.9,  with  its  different 
functionality,  from  (the  proof  of)  Program  1.6. 

In  general,  proof  transformations  can,  like  pruning,  both  exploit  and  preserve  more  information 
than  pure  program  transformations  can.  By  “pure”  program  transformations  we  mean  those  that 
exploit  only  the  information  inherent  in  the  text  of  the  program.  They  may  alter  functionality,  but 
only  in  very  constrained  ways  like  specialization.  Since  a  theorem  (i.e.,  the  specification)  may  have 
many  different  proofs,  with  corresponding  programs  of  different  functionality,  proof  transformation 
has  the  potential  to  produce  a  final  implementation  that  computes  a  different  function  from  that  of 
the  initial  implementation,  as  the  pruning  example  shows.  A  proof  transformation  may  even  alter 
the  specification:  its  validity  consists  in  the  property  that,  if  the  original  proof  P  is  a  valid  proof 
of  some  proposition  P,  then  the  resulting  proof  V  is  a  valid  proof  of  some  proposition  P\  where 
P  and  P'  need  not  be  the  same.  Translated  into  the  programming  world,  this  means  that  a  proof 
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transformation  can  give  us  a  program  for  the  specification  P\  given  a  program  for  the  specification 
P. 


1.4  Objectives  of  the  thesis 


The  general  motivation  of  this  work  is  the  hope  of  bringing  the  proofs-as-programs  strategy  closer 
to  application  to  real  programming  tasks.  We  set  out  to  explore  how  proof  transformation  may  be 
used  to  attack  some  of  the  obstacles  to  this  goal,  in  particular  those  noted  by  Pfenning:  the  tradeoff 
between  elegant  proofs  and  efficient  programs,  and  the  need  to  adapt  to  changing  specifications. 
Along  the  way  we  have  learned  much  about  the  strengths  and  weaknesses  of  a  logical  framework- 
based  approach  to  formulating  proof  transformations. 

The  principles  that  have  guided  this  research  are  that  first,  it  is  best  to  separate  proof  trans¬ 
formation  from  the  problem  of  theorem  proving;  and  second,  proof  transformations  should  be 
expressed  in  an  understandable  and  verifiable  way.  These  principles  are  motivated  by  the  following 
observations. 

Research  on  automated  support  for  theorem  proving  is  an  active  area,  and  there  are  several 
competing  approaches,  each  with  its  strengths  and  weaknesses.  As  a  research  strategy,  the  separa¬ 
tion  of  proof  transformation  and  theorem  proving  is  valuable  as  a  way  to  isolate  the  contributions 
transformation  may  offer  to  problem  solving.  We  should  note  however  that  our  approach  is  predi¬ 
cated  on  the  existence  of  proof  objects  of  a  particular  kind.  These  are  not  available  from  all  provers 
(e.g.  the  Boyer-Moore  Theorem  Prover  [BM79])  although  in  principle  there  seems  to  be  no  reason 
why  they  could  not  be  constructed. 

The  idea  that  transformations  should  be  expressed  in  an  understandable  way  is,  we  hope,  non- 
controversial.  Understandability  is  a  widely  accepted  goal  for  programs  in  general,  thus  for  the 
metaprograms  that  implement  proof  transformations.  Lit  understandability  of  proof  transfor¬ 
mations  may  also  have  importance  for  the  documentation  of  the  extracted  program.  In  a  pure 
proofs-as-programs  strategy  without  transformation,  the  proof  is  considered  to  be  the  formal  basis 
for  an  explanation  of  the  program.  But  the  tradeoff  between  elegance  and  efficiency  intervenes: 
because  of  its  complexity,  the  proof  of  a  highly  optimized  program  may  not  be  much  good  as  an 
explanation.  An  automatically  synthesized  (by  transformation  and  theorem  proving)  proof  is  also 
not  an  explanation  if  the  proof  is  too  complex  and  the  synthesis  process  is  not  transparent.  Thus 
we  want  the  proof  transformations  as  part  of  the  explanation  of  the  program.  Our  work  exploits 
the  logical  framework  approach,  and  declarative  aspects  of  the  logic  programming  style,  to  achieve 
executable  proof  transformations  that  can  be  read  as  derived  logical  rules. 

The  verifiability  of  transformations  is  perhaps  less  critical,  siiice  the  program  resulting  from 
a  transformation  is  verified  by  a  combination  of  proof  checking  and  program  extraction.  But 
in  principle  transformations  should  be  correct  in  general;  moreover,  it  is  often  useful  to  know 
something  more  than  that  a  transformation  produces  a  valid  proof.  We  may  want  to  know  also  the 
end-formula  of  the  proof,  or  some  structural  feature  of  the  proof.  The  use  of  a  logical  framework 
contributes  to  these  goals.  We  give  transformations  that  can  be  encoded  as  derived  rules,  and  thus 
verified  in  general  by  a  proof  checker  (the  type  checker  of  the  framework). 
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1.5  Research  contributions 

The  thesis  makes  contributions  in  two  main  areas:  the  formalization  of  proofs-as-programs  and 
proof  transformations  as  a  set  of  deductive  systems  in  a  logical  framework,  and  the  formulation  of 
program  transformations  as  proof  transformations. 

We  give  a  partially  verified  implementation  in  Elf  of  basic  support  for  the  proofs-as-programs 
methodology:  a  constructive  logic,  a  functional  programming  language,  and  the  extraction  of  pro¬ 
grams  from  proofs.  The  ideas  behind  the  implementation  and  verification  are  not  new  (see  Sec¬ 
tion  1.6  on  related  work  for  sources);  our  contribution  has  been  to  synthesize  them  in  a  working 
implementation  and  to  use  it  to  develop  and  transform  proofs  and  extract  programs.  Our  imple¬ 
mentation  of  proof  transformations  is  limited  to  those  that  can  be  expressed  as  derived  rules  of 
the  object  logic,  although  there  is  nothing  in  the  underlying  implementation  that  prevents  more 
complex  analysis  and  transformation.  This  formulation  is  declarative,  easily  verifiable,  readily 
extensible,  and  independent  of  the  theorem-proving  problem.  The  implementation  as  a  whole  is 
partial  evidence  for  the  feasibility  of  the  metalogical  framework  approach  to  metaprogramming  for 
logic  advocated  by  Basin  and  Constable  in  [BC93],  although  our  approach  is  a  hybrid,  combining 
the  weak  framework  LF  and  the  logic  programming  capabilities  of  Elf. 

We  have  shown  that,  perhaps  surprisingly,  useful  program  transformations  translated  to  the 
level  of  proof  transformation  can  be  formulated  as  derived  rules  of  the  object  logic.  We  have  done 
this  for  two  well-known  program  transformations.  This  suggests  that  the  extensive  research  effort 
that  has  been  devoted  to  codifying  program  transformations  can  be  rather  easily  translated  into  the 
domain  of  proof  transformation.  An  alternative  view  is  that  proof  transformation  techniques  can 
be  used  to  enrich  program  transformation  by  providing  a  simple  syntactic  formal  representation 
of  the  semantic  information  that  justifies  a  transformation.  Our  case  studies  also  provide  more 
evidence  for  Goad’s  thesis  that  proof  transformation  can  achieve  results  not  available  from  purely 
syntactic  program  transformation. 


1.6  Related  work 

In  his  thesis  Peter  Madden  [Mad91]  also  extends  the  work  of  Goad  along  the  lines  suggested 
by  Pfenning’s  paper.  He  describes  a  complete  Prolog-based  reimplementation  of  Goad’s  pruning 
transformation,  extends  it  to  an  implementation  by  proof  transformation  of  the  tupling  program 
transformation  strategy,  and  sketches  an  extension  to  divide-and-conquer  transformations.  This 
work  aims  at  full  automation,  including  automatic  theorem  proving  as  well  as  selection  of  proof 
transformation  strategies.  Thus  there  is  a  major  difference  in  philosophy:  where  we  are  concerned  to 
separate  transformation  from  proving  and  from  heuristic  concerns,  and  to  express  transformations 
as  transparently  as  possible,  Madden’s  work  emphasizes  automated  deduction. 

Chetan  Murthy’s  thesis  [Mur90]  studies  translations  from  classical  to  constructive  logic,  which 
allow  programs  to  be  extracted  that  capture  the  computational  content  of  certain  classical  proofs. 
His  work  focuses  on  the  relationship  between  classical  reasoning  and  nonlocal  control  operations, 
and  the  exploitation  of  the  relationship  to  obtain  total-correctness  proofs  of  programs  using  nonlocal 
control.  Unlike  the  simple  uniform  transformations  we  study  here,  Murthy’s  translation  is  defined 
by  structural  induction  on  proof  trees,  and  considerable  engineering  expertise  was  required  to  obtain 
a  feasible  implementation.  This  implementation  takes  the  standard  approach  of  metaprogramming 
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in  ML,  rather  than  the  framework- based  approach  of  our  work. 

Christophe  Raifalli,  in  [Raf93],  describes  the  use  of  proof  translation  to  compile  functional 
programs  for  an  SEC  abstract  machine.  He  gives  a  type  system  and  an  operational  semantics  for 
the  abstract  machine,  shows  the  soundness  of  the  semantics  with  respect  to  the  type  system,  and 
gives  a  translation  from  natural  deduction-style  proofs  in  second-order  logic  to  the  machine  logic. 

Working  in  an  essentially  “linear”  context,  Sieg  and  Wainer  [SW93]  have  investigated  proof 
translations  in  which  recursive-to-tail-recursive  program  transformation  corresponds  to  the  elimi¬ 
nation  of  what  they  call  “call-by-value”  cuts. 

The  basic  techniques  used  in  our  EH  implementation  were  developed  in  [HM89],  {Han91], 
[HHP93],  and  [MP91].  The  partial  internalization  of  the  metatheory  uses  methods  described 
in  [HP92],  [PR92],  and  [Pfe92a]. 

The  procedure  we  use  for  optimizing  code  during  program  extraction  is  directly  derived  from 
techniques  developed  by  Hayashi  (Hay90]  for  PX,  Paulin- Mohring  [PM89]  for  the  Calculus  of  Con¬ 
structions,  and  Sasaki  [Sas86]  for  Nuprl.  Goad  [Goa80]  and  Schwichtenberg  [Sch82],  [Sch85]  use 
similar  ideas  to  reduce  the  size  of  the  representation  of  the  computational  contents  of  a  proof. 


1.7  Outline  of  the  thesis 

There  are  two  main  parts  to  the  thesis:  a  description  of  the  Elf  implementation  of  proofs-as- 
programs  and  proof  transformations,  and  some  case  studies  of  graph  search  algorithms. 

•  Chapter  2  gives  a  short  introduction  to  the  Edinburgh  Logical  Framework  and  the  Elf  lan¬ 
guage,  then  describes  the  Elf  encoding  of  proofs,  programs,  and  the  extraction  of  programs. 

•  Chapter  3  presents  some  of  the  metatheory  of  extraction,  with  a  partial  formalization  of  it  in 
Elf. 

•  Chapter  4  demonstrates  by  example  a  method  of  encoding  and  applying  a  limited  class  of 
proof  transformations.  A  transformation  for  converting  a  program  to  tail-recursive  form  is 
given,  first  informally,  then  fully  formalized  in  Elf.  Then  it  is  applied  to  a  small  programming 
problem, 

•  Chapter  5  presents  some  case  studies,  applying  proof  transformation  to  breadth-first  and 
depth-first  search.  Here  the  emphasis  is  on  the  program  development  problem  rather  than  on 
the  formulation  of  the  proof  transformations. 

•  Chapter  6  gives  a  summary  and  a  discussion  of  directions  for  future  research. 

•  In  the  appendices  we  provide  listings  of  Elf  code  with  a  description  of  how  to  access  our 
implementation  and  the  EH  system  by  ftp,  and  some  technical  remarks  on  the  adequacy  of 
EH  encodings  and  the  recognition  of  tail-recursive  object  programs. 
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Chapter  2 

Implementation 


This  chapter  describes  how  we  implemented  some  basic  support  for  proofs-as-programs  in  a  logi¬ 
cal  framework,  and  describes  techniques  of  higher-order  logic  programming  for  defining  inference 
systems  over  languages  represented  using  higher-ordei  abstract  syntax.  We  encoded  a  natural- 
deduction  style  constructive  logic  and  a  programming  language  in  the  Edinburgh  Logical  Frame¬ 
work  (LF)  [HHP93]  using  Elf  [Pfe89],  [Pfe91a],  a  logic  programming  language  based  on  LF.  Program 
extraction,  program  execution,  proof  transformations,  and  other  forms  of  term  manipulation  were 
implemented  as  Elf  logic  programs. 

Section  2.1  gives  a  brief  introduction  to  the  LF  and  Elf  languages  and  the  principles  guiding  their 
use  for  encoding  inference  systems.  Section  2.2  describes  the  encoding  of  natural  deduction  proofs 
for  a  first-order  constructive  logic.  Finally  in  Section  2.3  we  treat  program  extraction,  defining  a 
small  functional  programming  language  with  a  type  assignment  system  and  interpreter,  and  two 
forms  of  program  extraction  from  proofs. 


2.1  LF  and  Elf 

LF  is  a  typed  A-calculus  designed  to  serve  as  a  framework  for  the  encoding  of  logics  and  related 
formal  systems.  Its  type  system  is  expressive  enough  to  support  straightforward  encodings  of  many 
(though  not  all)  formal  deductive  systems  used  in  reasoning  about  programming  languages,  formal 
logics,  and  the  like.  The  decidability  of  the  type  system  gives  practical  force  to  the  judgments  as 
types  and  the  corresponding  proof-checking  as  type-checking  principles.  Elf  is  a  logic  programming 
language  that  gives  an  operational  semantics  to  LF  type  declarations:  an  Elf  program  is  a  collection 
of  type  declarations  and  an  Elf  query  is  a  type.  The  query  may  contain  free  variables,  which  are 
treated  like  Prolog  logic  variables;  it  succeeds  if  the  system  can  construct  an  inhabitant  of  the  query 
type  from  the  declarations  that  constitute  the  program. 

Elf  signatures  (collections  of  type  declarations)  may  be  used  as  language  definitions,  as  logic 
programs,  or  both.  In  a  language  definition,  types  and  type  declarations  are  used  in  a  way  that 
corresponds  to  the  usual  intuition:  they  are  syntactic  categories  and  declarations  of  constructors  for 
those  categories.  Signatures  used  in  this  way  are  called  static  and  are  not  used  for  search.  Dynamic 
signatures  are  programs  used  for  search,  which  implement  deductive  systems  for  making  certain 
kinds  of  judgments.  This  dual  nature  of  Elf  signatures  reflects  the  LF  principle  of  judgments-as- 
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types. 


2.1.1  The  LF  type  system 

First,  we  briefly  describe  the  LF  type  theory.  Harper  et  al.  [HHP93]  give  a  full  description;  here 
we  give  the  syntax  and  sketch  a  few  crucial  ideas  but  rely  on  examples  to  develop  a  feeling  for  the 
semantics.  LF  is  a  three-level  dependently-typed  A-calculus  of  objects,  families,  and  kinds.  Families 
classify  objects  and  include  ordinary  types;  kinds  classify  families. 

Kinds  K  Type  |  Hxt^l .  K 

Families  A  "=  a  \  HiiA.J?  |  Xx-.A.B  \  AM 

Objects  M  ::=  c  I  X  I  \x\A  .M  |  M  N 

The  binding  operators  11  and  A  bind  their  lirst  argument  x:A  in  the  second  argument  po¬ 
sition.  It  is  conventional  to  identify  terms  that  differ  only  in  the  names  of  bound  variables, 
and  the  usual  definitions  of  free  and  bound  variables  and  substitution  are  used.  The  notation 
[Mi,...,Mk/xi,...,Xk]N  denotes  the  term  that  results  from  the  simultaneous  substitution  of 
M\,...,Mk  for  free  occurrences  of  xi,...,Xk  respectively  in  the  term  N,  renaming  bound  vari¬ 
ables  as  needed  to  avoid  capture. 

Families  of  the  form  nx:.4.  B  are  product  types,  which  classify  functions  Axr.4  .  M  at  the  object 
level.  When  x  does  not  occur  free  in  B,  the  type  Hx;/!.  B  is  an  ordinary  function  type;  in  this  case 
it  is  customary  to  write  it  as  /I  fi.  The  H  operator  quantifies  over  terms  at  the  object  level  only. 
The  application  of  one  of  these  families  to  an  object-level  term  x  reduces  to  a  type  that  depends 
on  the  value  of  x  (if  x  appears  free  in  B).  Similarly,  kinds  of  the  form  Hx:/!.  K  are  product  kinds, 
which  classify  dependent  type  families  XxiA.B.  Again  x  ranges  only  over  object-level  terms,  and 
when  X  is  not  free  in  K  we  write  A  —>■  K. 

The  crucial  properties  of  the  calculus  are  first,  the  decidability  of  the  type  system,  which  yields 
a  proof  checker  for  any  deductive  system  properly  encoded  in  it,  and  second,  the  existence  of 
canonical  forms,  which  permits  the  precise  statement  and  proof  of  the  correctness  of  an  encoding. 
We  discuss  the  correctness  of  the  encodings  of  this  chapter  in  Appendix  B  Rather  than  reproduce 
the  calculus  in  full  here,  we  refer  the  reader  to  [HHP93];  but  in  order  to  discuss  the  principles  of 
the  encodings  we  use,  we  describe  some  of  its  features. 

The  rules  of  the  calculus  assign  a  type  A  to  an  object-level  term  M  in  a  context  F  and  a  signature 
E.  Similarly  they  assign  a  kind  K  to  a  type  A  in  a  context  F  and  a  signature  E.  Signatures  and 
contexts  have  the  same  structure  and  are  used  to  maintain  a  typing  environment,  signatures  being 
used  to  record  the  types  and  kinds  of  constants  and  contexts  being  used  to  record  the  types  of 
variables. 


Signatures  E  ::=  <>  |  T,,a\K  \  E,c:A 
Contexts  F  <>  j  F,c:A 

The  calculus  includes  rules  for  deducing  when  a  signature  or  context  is  valid,  which  guarantee 
that  variables  and  constants  are  not  “re-declared”. 
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Encodings  in  LF  of  deductive  systems  that  use  collections  of  assumptions  (for  example,  a  type 
assignment  system  for  a  programming  language,  or  systems  of  natural  deduction)  often  represent 
these  collections  of  assumptions  in  the  meta-level  context. 

Hence  it  is  important  to  keep  in  mind  the  properties  of  LF  contexts  stated  in  Theorem  2.3 
of  [HHP93].  We  sketch  them  here  at  an  intuitive  level: 

1.  Weakening:  a  type  or  kind  assignment  that  holds  in  a  context  F  holds  also  in  any  valid 
extension  of  F. 

2.  Strengthening:  a  type  or  kind  assignment  a  that  holds  in  a  context  F,a:  :  U,T'  holds  also  in 
F,  F'  provided  that  x  is  not  free  in  F'  or  in  o. 

3.  Transitivity:  if  the  type  assignment  M  :  A  holds  in  context  F,  and  the  assignment  q  holds  in 
context  Fji  :  i4,F',  then  the  assignment  [M/x]a  holds  in  the  context  F,[M/a;]F'. 

4.  Permutation:  if  the  assignment  a  holds  in  context  F,i  :  i4,F',j/  :  H,F",  then  it  holds  in  the 
context  T,y  :  B,T',x  :  i4,F",  provided  that  x  is  not  free  in  B  or  F'  and  J5  is  a  valid  type  or 
kind  in  F. 

There  are  two  important  principles  that  are  repeatedly  used  in  LF  representations  of  languages 
and  deductive  systems:  judgments  as  types  and  higher-order  abstract  syntax.  This  section  briefly 
introduces  these  principles;  as  they  are  encountered  in  the  implementation,  they  are  explained  more 
fully. 

The  principle  of  judgments  as  types  is  crucial  in  encodings  of  deductive  systems.  A  judgment 
is  the  relation  established  by  a  deductive  syrtem,  for  example,  the  truth  of  a  logical  formula  or  a 
typing  assignment  for  a  program  expression.  An  LF  encoding  of  a  deductive  system  represents  a 
proof  as  an  object  and  a  judgment  as  the  type  of  its  proof.  That  is,  to  encode  a  deductive  system 
in  LF,  one  declares  a  type  family  A  to  represent  the  judgment.  The  inference  rules  of  the  system 
are  represented  by  declaring  LF  object-level  constants  that  construct  objects  of  that  type  family. 
A  deduction  in  the  system  may  then  be  represented  as  an  LF  object;  it  is  a  valid  deduction  if  it 
can  be  given  type  A  in  the  LF  type  system.  Thus  the  principle  of  judgments-as-types  gives  rise  to 
the  corresponding  principle  that  proof  checking  (in  the  encoded  deductive  system)  is  type  checking 
(in  the  LF  system).  When  A  is  a  dependent  type  (has  a  H-kind),  LF  type  checking  can  guarantee 
some  correctness  properties  of  the  inference  system  that  would  otherwise  have  to  be  proved  in  an 
external  metatheory.  The  proof  transformations  of  section  4  are  an  example;  because  we  encode  the 
judgment  that  a  proposition  A  is  provable  as  a  dependent  type,  it  is  possible  to  implement  proof 
transformations  so  that  type  checking  guarantees  that  the  transformed  proof  is  not  only  valid,  but 
still  proves  the  same  proposition  A. 

Judgments  may  be  basic,  hypothetical,  or  schematic.  A  basic  judgment  is  one  established  by 
the  logical  system  to  be  encoded,  for  example,  that  a  formula  is  provable  in  first-order  logic.  We 
represent  a  basic  judgment  form  by  a  type  family  indexed  by  the  type(s)  of  the  subject(s)  of  the 
judgment.  A  hypothetical  judgment  states  that  a  judgment  B  is  deducible  from  an  assumption  A. 
In  LF  this  is  encoded  as  a  type  A  —y  B;  the  encoding  extends  in  an  obvious  way  to  encoding  B 
deducible  from  multiple  assumptions  A\ ...  An  ss  A\  —y  An  B.  A  schematic  judgment 

that  B  holds  for  any  term  x  of  type  A  is  encoded  as  a  dependent  function  type  Bx-.A.B. 
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Higher-order  abstract  syntax  eases  the  implementation  of  binding  constructs  in  language  defi¬ 
nitions.  Instead  of  explicitly  naming  variables  and  managing  substitutions,  the  user  can  declare  a 
binding  construct  as  an  LF  constant  that  takes  a  functional  argument  and  constructs  a  language 
expression.  Terms  are  constructed  by  applying  the  constant  to  LF  function  objects.  The  usual  rule 
of  /3-conversion  is  built  in  to  the  type  theor ,,  blowing  substitution  to  be  encoded  as  LF  application. 
This  technique  extends  beyond  language  d>  Unition  to  deductive  systems.  It  is  often  appropriate 
and  convenient  to  represent  assumptions  introduced  during  a  deduction  as  bound  variables  at  the 
meta-level,  instead  of  managing  them  explicitly.  As  long  as  the  object  deduction  system  obeys 
the  principles  of  weakening,  strengthening,  transitivity,  and  permutation  described  above  for  LF 
contexts,  this  kind  of  representation  is  faithful. 

2.1.2  The  Elf  language 

The  core  of  the  Elf  syntax  is  a  straightforward  translation  of  LF  syntax  into  a  limited  character 
set,  with  curly  braces  {}  playing  the  role  of  H  and  □  playing  the  role  of  A.  Type  annotations  may 
be  omitted;  we  indicate  this  by  enclosing  them  in  brackets  ().  The  symbol  id  stands  for  a  variable 
or  a  constant. 


Kinds 

kexp 

::=  type 

1  {id  {:f exp)} kexp 

Families 

fexp 

::=  id  \ 

[id  {: fexp)} fexp  \ 

Lid  {:fexp)']fexp  \  fexp  oexp 

Objects 

oexp 

::=  id  | 

lid  {:fexp)l  oexp  | 

oexp  oexp 

Elf  also  allows  the  use  of  arrow  notation  for  a  dependent  type  or  kind  {x:A}  H  where  x  is  not 
free  in  M.  For  use  in  dynamic  signatures,  which  are  viewed  as  logic  programs,  there  is  also  the 
backwards  arrow  notation  A  <-  B,  which  stands  for  LF’s  B  ^  A.  The  arrow  is  right-associative 
(as  usual),  while  the  backwards  arrow  is  left-associative.  Thus  there  is  an  additional  alternative  for 
the  category  of  Kinds  and  two  more  for  the  category  of  Families: 

Kinds  kexp  ::=  ...  |  fexp  ->  kexp 

Families  fexp  ::=  ...  |  fexp  ->  fexp  \  fexp  <-  fexp 

A  family  or  object  expression  may  be  annotated  with  its  kind  or  type.  This  is  useful  in  con¬ 
junction  with  Elf’s  type  and  term  reconstruction  since  it  can  be  used  to  name  parameters  that  are 
normally  left  implicit.  Thus  there  is  one  more  alternative  each  for  Families  and  Objects: 

Families  fexp  ::=  ...  |  fexp  :  kexp 

Objects  oexp  ::=  ...  )  oexp  :  fexp 

Parentheses  may  be  used  freely  to  limit  the  scope  of  bound  variables  and  change  the  associativity 
of  arrows  and  type  annotations.  Any  identifier  may  be  used  for  a  bound  variable  or  constant. 
Identifiers  free  in  a  (top  level)  family  or  kind  must  be  capitalized.  In  a  type  declaration  these  are 
implicitly  H-quantified.  In  a  query  they  are  treated  as  logic  variables.  Omitted  type  annotations 
and  the  types  of  free  variables  are  supplied  where  possible  by  Elf’s  type  reconstruction  mechanism. 

An  Elf  signature  is  a  collection  of  kind  and  type  declarations: 
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Declarations  decl  ::=  id:  kexp.  \  id:  fexp. 

A  signature  that  is  declared  as  static  is  not  used  for  search  and  serves  as  a  language  definition. 
Kind  and  family  declarations  in  these  signatures  estabhsh  syntactic  categories,  fitting  the  usual 
intuition  about  types.  However,  even  when  a  signature  is  not  used  for  search,  its  types  may 
be  thought  of  as  judgments.  This  is  seen  in  the  representation  of  natural-deduction  proofs  of 
section  2.2.2,  which  supports  simultaneously  a  treatment  of  proofs  as  objects  and  one  of  proofs  as 
ways  of  establishing  judgments. 

A  signature  declared  as  dynamic  may  be  viewed  as  a  logic  program  and  is  used  for  search  by 
the  Eli  interpreter.  Types  play  the  same  role  that  formulas  do  in  Prolog.  A  query  is  not  a  formula 
but  a  type,  which  may  contain  free  variables.  These  are  treated  like  the  logic  variables  of  Prolog: 
if  the  query  succeeds,  the  substitution  found  by  unification  during  type  reconstruction  or  search 
for  each  free  variable  is  displayed.  Higher-order  unification  is  used  instead  of  first-order  unification 
as  in  Prolog.  To  solve  a  query  the  interpreter  attempts  to  construct  an  object  of  the  given  type, 
using  the  declarations  in  the  dynamic  signatures  available.  If  the  query  succeeds,  this  object,  which 
represents  a  proof  of  the  goal  query,  is  available  as  well  as  the  substitutions  for  the  free  variables  of 
the  query.  The  proof  object  can  itself  be  used  in  further  goals.  An  example  of  this  usage  appears  in 
the  partially  internalized  proofs  of  correctness  for  the  implementation  in  chapter  3.  The  availability 
of  the  proof  object  again  manifests  the  dual  nature  of  signatures:  although  a  dynamic  signature  is 
usually  thought  of  as  a  program  for  establishing  judgments,  it  can  also  be  thought  of  cis  a  language 
definition,  with  its  constituent  declarations  as  constructors  of  terms  in  the  language.  These  terms 
may  themselves  be  objects  of  computation. 

An  important  feature  of  dynamic  signatures,  corresponding  to  the  use  of  higher-order  abstract 
syntax  in  static  signatures,  is  the  way  ordinary  and  dependent  function  types  serve  to  introduce 
assumptions.  When  the  interpreter  encounters  a  goal  that  is  a  function  type  A-*  Ais  added  to 
its  stock  of  rules  as  an  assumption  available  during  the  search  for  a  term  of  type  H,  causing  subgoals 
that  are  unifiable  with  A  to  succeed  in  that  search.  A  goal  may  also  have  dependent  function  type 
Tlx:A .  B,  with  x  free  in  B.  When  attempting  to  solve  such  a  goal  the  interpreter  creates  a  new 
parameter  xq  of  type  A  and  a  new  subgoal  B  with  xo  substituted  for  free  occurrences  of  x.  The  use 
of  dependent  types  as  subgoals  is  a  common  technique  in  Elf  programs  that  implement  deductive 
systems  over  terms  represented  as  higher-order  abstract  syntax.  In  such  a  system,  an  inference 
rule  that  analyzes  a  binding  construct  frequently  has  a  premise  that  depends  on  an  assumption 
about  the  bound  variable.  For  instance,  one  might  infer  a  type  for  a  A-abstraction  by  adding  a 
type  assignment  for  its  bound  variable  to  a  context  and  attempting  to  infer  a  type  for  its  body. 
Dependently  typed  assumptions  are  typically  used  in  encodings  of  inference  rules  of  this  form. 
The  technique  occurs  frequently  in  the  implementation  described  here;  there  is  a  more  detailed 
description  of  it  in  section  2.3.1. 


2.2  Logic 

This  section  describes  the  encoding  of  natural-deduction  style  proofs  for  intuitionistic  first-order 
predicate  calculus.  The  encoding  supports  the  manipulation  of  proofs  as  objects  rather  than  proof 
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search,  and  should  be  viewed  as  simply  a  set  of  constructor  definitions  defining  the  abstract  syntax 
of  a  logical  language  and  its  proof  system.  Thus  the  Elf  implementation  consists  of  a  static  signature 
for  each  “language”  -  the  language  of  propositions  and  the  language  of  proofs.  It  does  not  provide 
a  theorem  prover  for  natural  deduction. 

We  represent  propositions  of  first-order  predicate  calculus  as  object-level  LF  terms.  The  lan¬ 
guage  definition  is  a  signature  that  declares  the  logical  connectives  and  quantifiers  as  constructors. 
This  contrasts  with  other  treatments  of  constructive  logic  based  on  type  theories,  such  as  Nuprl 
and  the  Calculus  of  Constructions,  in  which  propositions  of  the  logic  are  identified  with  types  of 
the  type  theory. 

There  are  several  reasons  for  separating  the  type  of  propositions  from  LF  types.  LF  is  a  weak 
theory  that  does  not  include  quantification  over  types.  Thus  it  is  not  possible  in  LF  to  declare 
logical  connectives  as  functions  over  terms  of  kind  Type.  Why  then  choose  Elf  for  an  implementa¬ 
tion  language?  Proof  transformations,  program  extraction,  and  related  tasks  are  metaprogramming 
problems:  they  cannot  usually  be  implemented  for  a  type  theory  in  that  type  theory.  One  stan¬ 
dard  approach  to  metaprogramming  has  been  to  use  a  programming  language  such  as  ML  as  a 
metalanguage  for  a  type  theory  considered  as  an  object  logic.  We  want  to  implement  proof  trans¬ 
formations  and  other  metaprograms  in  a  flexible,  declarative  and  verifiable  way.  As  Basin  and 
Constable  [BC93]  argue,  these  goals  suggest  another  approach:  the  use  of  a  type  theory  as  a  met- 
alogical  framework.  Although,  as  they  point  out,  the  weakness  of  the  LF  type  theory  limits  the 
metareasoning  that  can  be  fully  internalized,  the  logic  programming  interpretation  provided  by  Elf 
affords  a  flexible  programming  tool  for  expressing  metatheory  in  a  declarative  way  that  also  yields 
executable  metaprograms.  The  availability  of  higher-order  abstract  syntax  yields  concise,  quickly 
implementable  encodings  for  many  (though  not  all)  deductive  systems.  This  is  a  good  setting  for 
experimenting  with  variations  on  the  object  logic,  the  syntax  and  semantics  of  the  programming 
language,  and  program  extraction,  without  the  need  to  modify  the  syntax  or  semantics  of  the  un¬ 
derlying  type  theory.  We  in  fact  exploit  this  by  exploring  two  definitions  of  program  extraction. 
While  one  must  expend  the  effort  to  explicitly  define  these  systems,  this  effort  is  typically  small, 
especially  when  higher-order  abstract  syntax  can  be  used.  The  reward  is  flexibility  in  choices  such 
as  the  definition  of  program  extraction,  and  the  syntax  and  semantics  of  the  programming  language 
used  for  extraction. 

2.2.1  Logical  language 

Our  encoding  of  first-order  constructive  logic  follows  the  method  described  in  Harper  et  al.  [HHP93]. 
To  simplify  the  exposition,  we  show  the  representation  for  a  logic  with  only  a  single  sort  of  indi¬ 
viduals,  interpreted  as  natural  numbers.  Later  in  the  presentation  we  show  how  to  modify  the 
definitions  to  represent  a  many-sorted  logic. 

An  abstract  syntax  for  the  logic  is: 

Individuals  t  ::=  x  |  zero  |  succ  t 

Propositions  A  ::=  T  (  X  (  Ay  t\  A2  [  Ay  y  A2  \  Ay  D  A2  | 

1  Vx .  A  1  3x .  A  1  ty=t2 

To  encode  this  syntax  in  LF  we  first  define  two  nev/  types,  o  for  the  type  of  propositions  and  i 
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for  the  type  of  individuals: 

o:  Type 
t:  Type 

Individuals  are  encoded  by  declaring  two  constants  for  representing  zero  and  the  successor 
function: 

zero:  i 
succ  :  i  i 

There  is  no  declaration  corresponding  to  individual  variables;  they  are  represented  as  LF  bound 
variables  through  the  use  of  higher-order  abstract  syntax. 

Connectives  are  encoded  in  a  straightforward  way  as  syntactic  constructors.  Binary  constructors 
are  curried  since  there  are  no  finite  products  in  LF. 

T:  o 
±:  o 

~i:  0-^0 

A  :  o  o  o 

V  :  o  o  o 

D  :  o  o—*  o 

The  equality  predicate  is  encoded  with  a  curried  function  type  as  well: 

=  :  i  i  —*  o 

The  encoding  of  quantifiers  is  a  simple  use  of  higher-order  abstract  syntax.  Each  quantifier 
is  encoded  as  a  constructor  that  takes,  not  a  proposition,  but  a  function  from  an  individual  to  a 
proposition.  The  binding  properties  of  the  quantifiers  are  expressed  by  LF  A-binding.  For  example, 
in  the  proposition  'ix  .x  =  x  the  two  occurrences  of  a:  in  the  equality  are  bound  by  the  quantifier. 
The  LF  representation  is  V(Aa::i.i  =  x),  an  application  of  the  constructor  V  to  an  LF  object  of 
functional  type.  Thus  the  schematic  nature  of  a  universally  or  existentially  quantified  proposition  is 
captured  by  the  LF  meta-language  and  does  not  have  to  be  explicitly  managed.  Only  the  semantic 
distinction  -  the  universal  vs.  existential  nature  of  the  proposition  -  is  left  to  be  expressed  by  the 
encodings  of  inference  rules,  reductions,  etc. 

V:  (i  — »  o)  — o 
3:  (i  o)  -K) 

The  Elf  signature  (Figure  2.1)  corresponding  to  the  LF  declarations  presents  no  additional 
complications.  The  differences  are  due  purely  to  the  concrete  syntax  of  Elf. 

2.2.2  Natural  deduction 

In  our  encoding  of  proofs,  again  following  Harper  et  al.  [HHP93],  we  use  the  dependent  types  of  LF 
to  ensure  that  proof  checking  is  LF  type  checking  -  even  though  propositions  are  object-level  terms. 
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o  :  type, 
i  :  type. 

zero  :  i. 
succ  :  i  ->  i. 
eq  :  i  ->  i  ->  o. 

true  :  o. 
false  :  o. 
not  :  o  ->  o. 
and  :  o  ->  o  ->  o. 
or  :  o  ->  o  ->  o. 
implies  :  o  ->  o  ->  o. 
forall  :  (i  ->  o)  ->  o. 
exists  :  (i  ->  o)  ->  o. 


Figure  2.1:  Elf  encoding  of  first-order  logic 


not  LF  types.  Higher-order  abstract  syntax  supports  the  representation  of  the  introduction  and 
discharge  of  assumptions,  as  well  as  the  side  conditions  restricting  the  free  occurrences  of  variables 
in  assumptions. 

As  is  customary,  we  use  a  tree-like  notation  in  our  presentations  of  natural  deduction  proofs. 
Assumptions  are  at  the  leaves,  and  a  formula  follows  from  zero  or  more  formulas  immediately 
above  it  by  one  of  the  inference  rules  of  the  system.  Assumptions  may  be  discharged  or  closed  by 
an  inference  (e.g.,  implication  introduction);  an  undischarged  assumption  is  often  called  open.  We 
say  a  formula  depends  on  the  open  assumptions  above  it  in  the  proof  tree.  The  last  formula  (at 
the  root  of  the  tree)  of  a  proof  is  a  theorem  if  it  does  not  depend  on  any  open  assumptions.  There 
is  no  distinguished  set  of  axioms,  though  we  sometimes  refer  to  an  inference  rule  with  no  premises 
as  an  axiom. 

Figure  2.2  gives  the  inference  rules  for  natural-deduction  style  proofs  in  an  intuitionistic  first- 
order  predicate  logic.  The  discharge  of  an  assumption  A  by  an  inference  rule  is  indicated  by  placing 
an  annotated  bar  over  A: 

-P 

A  The  corresponding  rule  is  indicated  by  a  matching  superscript  (e.g.  dI^).  We  use  either 
numbers  or  letters  for  superscripts,  depending  on  the  context.  Letters  are  useful  in  the  context 
of  program  extraction,  where  a  discharged  assumption  corresponds  to  a  bound  variable  in  the 
extracted  program.  Substitution  is  notated  as  follows:  [t/z]A  denotes  the  substitution  of  t  for  free 
occurrences  of  x  in  A.  We  use  this  notation  freely  in  subsequent  language  definitions,  assuming 
standard  definitions  of  bound  and  free  occurrerces,  and  the  ability  to  rename  variables  whenever 
necessary.  The  usual  conditions  on  free  occurrences  of  variables  apply  to  the  quantifier  rules 
annotated  with  an  asterisk.  In  a  proof  of  Vx .  A  ending  in  the  use  of  the  rule  vi,  the  variable  x 
cannot  occur  free  in  any  undischarged  assumption.  In  a  proof  of  C  by  be  with  3x .  A  as  major 
premise,  the  variable  x  cannot  occur  free  in  C  or  in  any  undischarged  assumption  on  which  the 
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Figure  2.2:  Natural  deduction  rules  for  first-order  logic 
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t2  = 

=  <2 


ti  =  t2  t2  =  <3 

- =T 

ti  =  <3 


—h—Jl— 


SUCC  <1  =  SUCC  t2 

- AXO - AXS 

-isucc  t  =  zero  ti  =  <2 

-P 

A 


[zero/x]i4  [succ  x/x]i4 
'ix  .A 


indp 


Figure  2.3:  Inference  rules  for  equality  and  arithmetic 
subproof  of  C  depends. 

Figure  2.3  presents  inference  rules  for  interpreting  the  individuals  of  the  logic  as  natural  numbers. 
For  simplicity  in  the  presentation  we  defer  discussion  of  other  theories  to  later  sections. 

Note  that  the  treatment  of  assumptions  and  the  side  conditions  on  variable  occurrences  means 
that  the  inference  rules  dI,  vi,  vE,  3E,  and  IND  are  binding  constructs.  Consider  implication  intro¬ 
duction: 

-P 

A 


B 

Ad  B 


DIP 


Here  p  is  a  name  for  a  hypothetical  proof,  as  the  bound  variable  in  a  A-abstraction  is  a  name 
for  a  hypothetical  value.  The  scope  of  p  is  limited  to  the  subproof  ending  in  the  application  of 
Dl  labelled  p;  no  other  part  of  the  proof  tree  can  include  assumptions  of  A  labelled  p.  Many  of 
the  operations  on  proofs  needed  in  the  implementation,  including  program  extraction  and  proof 
transformation,  use  the  substitution  of  proofs  for  assumptions  and  terms  for  quantified  variables 
in  a  way  that  conforms  to  LF  /^-reduction.  Such  usage  motivates  the  higher-order  abstract  syntax 
approach  to  the  encoding  of  proofs. 

A  proof  of  a  minimal  correctness  criterion  for  this  kind  of  encoding  of  natural  deduction  is  given 
by  Harper  et  al.  [HHP93]. 

Figure  2.4  shows  the  LF  encoding  of  the  logical  inference  rules;  Figure  2.5  shows  the  encoding 
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pf :  o  Type 
TI;  pfT 

IE:  nC:o.  pf  ± pf C 
AI:  nyl:o.n5:o.  pf  i4 -♦  pf  B  — ►  pf  A  B 
AEjt :  11/4:0.  nB:o.  pf(  A  A  B) pi  A 
AEfl  :  11/4:0. nfl:o.  pf(/4  A  5) -+ pf  JB 
Vli  :  nA:o.nB:o.  pf  A -♦  pf(i4  V  B) 

VE:  nA:o.nB:o.  pf(A  V  B) (pf  A pf  C)  -  (pf  B  ^  pf  C)  ^  pf  C 
Vlfl  :  nA:o.nB:o.  pf  B  ^  pf(A  V  B) 

DI:  nA:o.nB:o.(pfA-»pfB)^pf(ADB) 

DE :  nA:o .  nB:o .  pf(  A  D  B)  — ►  pf  A  — ►  pf  B 
V’ :  nA:(i  — ►  o) .  (nx:i .  pf(  Ax))  -+  pf(VA) 

VE :  nA:(i  ^  o) .  Bt.i .  pf(VA)  ->  pf  A{t) 

3I :  nA:(i  ^  o) .  n<:i .  pf  Ai  pf(3A) 

3E  :  n A:t  -♦  o .  pf  3A  -►  (IIx:* .  pf  Ax  pf  C)  -*■  pf  C 


Figure  2.4:  LF  encoding  of  logical  inference  rules 


=REFL :  Hi:* .  pi{t  =  t) 

=SYM :  Ilfi:* .  nf2:»  •  pf(<2  =  <i)  pf(<i  =  ^2) 

=TRANS  :  nfi:i.nf2:»-nf3:t .  pf(fj  =  t^)  -+  pf(f2  =  ^3)  — >  pf(fi  =  tz) 
=SUBST :  n/:*  — >  i .  Ilfi  :t .  nf2:i  •  nf3:i .  pf(ti  =  tz)  —*  pf (/(<i)  =  /(<2)) 
AXO :  V(Ax .  -isucc  x  =  zero) 

AXSUCC :  V(Ax .  VAy .  succ  x  =  succ  y) 

IND :  HA:*  — *■  o .  pf  A  zero  -+  (Hx:* .  pf  Ax  — ^  pf  A(succ  x))  — »  pf  VA 


Figure  2.5:  LF  encoding  of  inference  rules  for  equality  and  arithmetic 
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of  rules  for  equality  and  arithmetic.  The  encoding  is  based  on  the  declaration  of  a  dependent  type 
constructor  (family): 

pf :  Type 

The  dependent  type  provides  an  association  between  a  proof  and  the  proposition  it  proves,  encoded 
within  the  LF  type  of  the  term  representing  the  proof.  This  association  permits  the  encoding  of 
inference  rules  to  enforce  the  constraint  that  any  well-typed  proof  term  is  a  valid  proof,  i.e.,  to 
maintain  the  principle  that  proof  checking  is  LF  type  checking. 

For  example,  the  rule  of  conjunction  elimination  on  the  left  is  encoded  as  follows. 

AEx, :  nA:o.nB:o.  pf(A  A  B) —>■  pf  A 

This  defines  the  constructor  AEi,  as  a  function  that  takes  as  input  propositions  A  and  B,  and  a 
proof  of  A  A  B.  The  constructed  term  has  type  pf  A,  i.e.,  it  represents  a  proof  of  A.  Because  of  the 
dependent  type,  LF  type  checking  prevents  the  construction  of  an  incorrect  proof.  For  instance, 
there  is  no  way  to  represent  the  application  of  AE^  to  a  proof  of  T  by  TI,  since  it  has  type  pf  T. 
The  other  inference  rules  not  involving  bound  variables  or  assumptions  are  encoded  similarly. 
A  simple  use  of  higher-order  abstract  syntax  occurs  in  the  encoding  of  the  rules  DI ,  where  it  is 
used  to  express  the  discharge  of  an  assumption,  and  VI,  where  it  is  used  to  express  the  restriction 
on  free  occurrences  of  the  universally  quantified  variable. 

The  rule  DI 

-P 

A 


B 

Ad  B 


DI" 


is  encoded  as  follows. 


DI:  nA:o .nB:o.(pf  A -*  pf  B) —>■  pf(A  D  B) 

This  declaration  defines  the  constructor  DI  as  a  function  that  takes  propositions  A  and  B,  and  a 
function  from  proofs  of  A  to  proofs  of  B,  and  constructs  a  proof  of  A  D  B. 

A  small  example  proof  shows  how  functional  abstraction  in  LF  models  the  use  of  assumptions. 
Consider  the  following  deduction. 


- p 

zero  =  succ  zero 

- DIP 

zero  =  succ  zero  D  zero  =  succ  zero 

Its  LF  representation  is  the  closed  term: 

DI  (zero  =  succ  zero)(zero  =  succ  zero)(Ap:pf(zero  =  succ  zero)  .p) 

This  term  has  type  pf(zero  =  succ  zero  D  zero  =  succ  zero). 
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On  the  other  hand,  the  following  deduction  contains  an  undischarged  assumption  and  cannot 
be  represented  by  a  closed  LF  term: 

- P 

zero  =  succ  zero 

- DI" 

zero  =  succ  zero  D  zero  =  succ  zero  zero  =  succ  zero 

- Al 

(zero  =  succ  zero  D  zero  =  succ  zero)  A  zero  =  succ  zero 
In  the  corresponding  LF  term: 

AI  ((zero  =  succ  zero)  D  (zero  =  succ  zero))  (zero  =  succ  zero) 

(DI  (zero  =  succ  zero)  (zero  =  succ  zero)  (Ap:pf(zero  =  succ  zero)  .p))p 

the  second  occurrence  of  p  is  free,  representing  the  open  assumption. 

Similarly,  the  encoding  of  VI  models  the  schematic  nature  of  the  premise  and  enforces  the 
stipulation  that  there  be  no  free  occurrences  of  the  quantified  variable  in  any  open  assumption. 
The  rule  is  encoded  as  follows: 

VI :  EAii  ^  o) .  (ni:i .  pf(>lx))  pf (V/1) 

The  constructor  VI  has  two  functional  inputs.  The  first,  of  type  i  — ►  o,  represents  a  proposition 
that  is  schematic  in  an  individual  x.  The  second,  of  (dependent)  type  (nx:t .  pf(i4x)),  represents  a 
schematic  proof.  The  constructed  term  represents  a  proof  (in  which  the  VI  rule  acts  as  binder)  of 
a  universal  quantification  over  x  (in  which  V  acts  as  a  binder). 

As  an  example,  we  examine  the  representation  of  the  foUowing  proof: 

- =R 

X  =  X 

- VI 

Vx .  X  =  X 

This  is  encoded  as: 

Vl(Ax:t.x  =  x)(Ax:t.  =REFLx) 

Now  consider  the  following  “deduction” ,  which  is  invalid  because  x  occurs  free  in  an  undischarged 
assumption. 

X  =  zero 
- VI 

Vx  .  X  =  zero 

This  cannot  be  represented.  An  attempt  to  represent  it  might  begin: 

Vl(Ax:i .  X  =  zero)(Ax:i .  . . .) 

But  there  is  no  constructor  that,  given  a  term  x  of  type  i,  constructs  a  proof  of  x  =  zero. 

The  representation  of  the  other  inference  rules  involving  the  discharge  of  assumptions  and  the 
binding  of  variables  follows  the  same  principles. 

The  expression  of  these  LF  declarations  in  the  Elf  language  (Figure  2.6)  is  straightforward, 
except  for  the  use  of  implicit  quantification,  which  is  used  to  reduce  the  verbosity  of  the  “pure”  LF 
declarations. 

The  declaration  of  the  type  family  of  proofs  is  identical  to  the  LF  declaration,  but  we  use  the 
turnstile-like  notation  “  I  -”  in  place  of  the  constructor  pf . 
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|-  :  o  ->  type, 
true!  :  I-  true. 

falsee  :  {C:o}  I-  fedse  ->  I-  C. 

andi  :  I-  A  ->  I-  B  ->  1-  (and  A  B) . 
andel  :  I-  (and  A  B)  ->  I-  A. 

ander  :  I-  (and  A  B)  ->  |-  B. 

oril  :  {B:o}  |-  A  ->  |-  (or  A  B) . 

orir  :  {A:o}  |-  B  ->  |-  (or  A  B) . 

ore  :  I-  (or  A  B)  ->  (|-  A  ->  |-  C)  ->  (|-  B  ->  |-  C)  ->  |-  C. 

impliesi  :  ((-  A  ->  |-  B)  ->  (-  (implies  A  B) . 
impliese  :  |-  (implies  A  B)  ->  |-  A  ->  I-  B. 

noti  ;  (I-  A  ->  |-  false)  ->  I-  (not  A), 
note  ;  I-  (not  A)  ->  I-  A  ->  I-  false. 

foralli  :  «x:i}  I-  (Ax))  ->  |-  (forall  A), 
foralle  :  {T:i}  I-  (forall  A)  ->  |-  (AT). 

exists!  :  {A:i  ->  o}  {T:i}  |-  (AT)  ->  |-  (exists  A), 
existse  :  |-  (exists  A)  ->  «x:i}  |-  (Ax)  ->  |-  C)  ->  |-  C. 

eq.refl  :  {Xii}  |-  (eq  X  X). 

eq.sym  :  I-  (eq  X  Y)  ->  (-  (eq  Y  X). 

eq.trans  :  |-  (eq  X  Y)  ->  |-  (eq  Y  Z)  ->  |-  (eq  X  Z) . 

eq.subst  :  |-  (eq  X  Y)  ->  |-  (eq  (succ  X)  (succ  Y)). 

ax.zero  :  |-  (forall  [x]  (not  (eq  (succ  x)  zero))). 

ax_succ  :  I-  (forall  [x]  (forall  [y]  (implies  (eq  (succ  x)  (succ  y)) 

(eq  X  y)))) . 

ind  :  {A:i  ->  o}  |-  (A  zero)  ->  ({x:i}  I-  (Ax)  ->  |-  (A  (succ  x))) 
->  I -  (forall  A) . 


Figure  2.6:  Elf  encoding  of  logical,  equality,  and  arithmetic  inference  rules 
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|-  :  o  ->  type. 


Because  of  Elf’s  term  and  type  reconstruction  facility,  some  arguments  of  the  LF  declarations  can 
be  omitted  in  the  Elf  encoding,  and  reconstructed  during  type  checking.  For  example,  the  LF 
declaration  for  conjunction  introduction  is 

AI :  ni4:o.nB:o.  pf  >1  ^  pf  B -+ pf  A  B. 

But  in  Elf  this  can  be  written 

andi  :  |-  A  ->  |-  B  ->  |-  (and  A  B) . 


A  and  B  are  implicitly  quantified  in  this  declaration.  When  type  checking  the  declaration  Elf’s 
type  reconstruction  can  infer  that  A  and  B  must  have  type  o  since  |-  takes  a  term  of  that  type. 
When  constructing  a  term  by  this  rule  the  two  propositions  are  not  supplied  explicitly,  since  Elf 
reconstructs  them  from  their  proofs. 

On  the  other  hand,  consider  the  following  declaration: 

falsee  :  {Cio}  |-  false  ->  I-  C. 


If  C  were  not  explicitly  quantified,  type  reconstruction  could  still  produce  the  correct  type  for  the 
declaration.  But  to  use  the  rule  in  the  construction  of  a  proof,  it  is  sometimes  necessary  to  explicitly 
supply  C  since  it  cannot  always  be  inferred  from  the  input  proof.  Therefore  we  include  the  explicit 
quantification  in  the  declaration  so  that  an  actual  parameter  for  C  is  accepted  by  the  Elf  front  end 
when  the  user  inputs  a  proof.  An  alternative  method  is  to  make  the  parameter  implicit: 

falsee  ;  |-  false  ->  |-  C. 


Then  if  C  cannot  be  inferred  from  the  context,  it  can  be  specified  in  a  type  annotation,  e.g. 
implies!  [p:  I-  false]  (falsee:  |-  (eq  zero  (succ  zero))) 


2.3  Program  extraction 

To  implement  the  extraction  of  programs  from  proofs,  we  first  define  a  simple  language  of  functional 
programs.  The  syntax  of  the  language  is  implemented  in  Elf  according  to  the  same  principles  used 
in  the  definition  of  predicate  calculus  in  section  2.2.1.  A  typing  discipline  and  operational  semantics 
for  the  language  are  defined  in  the  form  of  deductive  systems  encoded  as  dynamic  Elf  signatures. 
As  with  the  encoding  of  logic,  the  representation  of  programs  is  external  to  the  underlying  logical 
framework.  Our  encodings  are  in  the  style  of  those  given  by  Michaylov  and  Pfenning  for  a  fragment 
of  ML  in  [MP91],  which  extend  the  higher-order  representations  developed  in  AProlog  by  Hannan 
and  Miller  in  [HM89],  [Han91]. 
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2.3.1  Programming  language 

Because  we  are  explicitly  defining  a  language  for  extracted  programs,  external  to  the  LF  type 
theory,  there  are  syntactic  and  semantic  choices  open  to  us.  The  language  presented  here  is  a 
simple  extension  of  a  A-calculus  with  primitive  recursion,  pairs,  and  disjoint  union,  with  a  call-by¬ 
value  semantics.  The  language  constructs  are  chosen  to  correspond  closely  to  the  inference  rules 
of  the  logic.  Extraction  into  more  expressive  languages  is  not  difficult  to  implement  along  similar 
lines,  and  we  have  done  so  for  a  miniML-like  language. 

Syntax  of  expressions  and  types 

In  the  presentation  of  extraction  and  its  meta-theory  we  use  a  Nuprl-like  syntax  for  programs  [C'*'86] 
in  order  to  emphasize  the  close  relation  to  the  logic.  (The  semantics  of  the  language,  however,  is  not 
the  Nuprl  semantics.)  A  BNF  grammar  for  the  language  follows;  it  consists  of  the  single  syntactic 
category  of  expressions  c. 


X  \ 

Variables 

0  1  s(e)  1 

Natural  numbers 

( 61,62)  1  fst(e)  1  snd(6)  |  spread(6,;  a:,2/.62)  | 

Pairs 

inl(6)  1  inr(e)  |  decide(6i;  i  .62;  x .  63)  | 

Disjoint  union 

latnx.6  1  natund(6i;  x,y.e2)  i  app(ei,C2)  | 

Functions 

0  1 

Unity 

any(6)  |  neg 

Error 

axiom 

Self-realizors 

(Later  in  the  presentation  we  add  more  language  constructs  as  we  deal  with  different  theories.) 

If  we  wish  only  to  extract  programs  from  proofs  and  execute  them,  there  is  no  need  to  consider  a 
type  structure  for  this  language.  However,  we  also  want  to  be  able  to  prove  (and  to  do  so  partially 
within  Elf)  some  metatheorems  about  the  correctness  of  extraction  and  program  execution.  For 
instance,  it  is  evident  from  the  interpretation  of  constructive  logic  described  in  Section  1.1  that  the 
type  corresponding  to  a  proposition  in  the  object  logic  of  the  form  A  A  B  should  be  a  product. 
Moreover,  the  evaluation  of  an  extracted  term  should  preserve  this  type.  In  order  to  reason  about 
such  properties  we  introduce  a  system  of  simple  types  for  the  language: 

Types  T  ::=  nat  |  ti  x  T2  \  ti\t2  |  Ti^  T2  \  unit  |  void  |  atom 

These  types  should  be  carefully  distinguished  from  the  types  of  the  LF  calculus;  we  sometimes  refer 
to  them  as  object  types. 

The  type  system,  the  operational  semantics  of  the  language,  and  their  role  in  representing  the 
computational  content  of  proofs  are  defined  precisely  in  the  form  of  deductive  systems  given  in  the 
rest  of  this  chapter.  Here  we  informally  sketch  the  main  outlines  of  these  ideas. 

The  program  extraction  process  expresses  the  computational  content  of  a  proof  in  the  form  of  a 
program,  losing  some  of  the  purely  logical  content  in  the  translation.  (Ideally,  all  of  the  purely  logical 
content  is  removed;  we  examine  some  of  the  issues  this  raises  in  section  2.3.2.)  The  propositions- 
as-types  principle  implies  a  similar  process  of  type  extraction:  to  each  logical  proposition  there 
corresponds  an  object  type  of  the  programming  language. 
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The  type  unit  is  inhabited  by  one  value,  (),  and  corresponds  to  logical  truth.  Thus  the  value  () 
is  extracted  from  the  rule  of  truth  introduction. 

A  pair  type  may  correspond  to  a  conjunction  or  an  existential.  When  ri  x  T2  corresponds  to 
A  /\  B,ti  corresponds  to  A  and  T2  to  B.  When  it  corresponds  to  Bar .  A,  ti  corresponds  to  the  sort 
of  ar  (in  the  object  logic  presented  so  far,  this  must  be  the  sort  of  natural  numbers  i,  but  later  we 
will  extend  the  object  logic  to  a  many-sorted  logic),  and  T2  corresponds  to  A.  Thus  pair  formation  is 
extracted  from  the  introduction  of  conjunction  or  existential  quantification.  The  usual  projections, 
fist  and  snd,  are  extracted  from  conjunction  eliminations.  The  destructor  spread  is  extracted  for 
existential  elimination.  The  evaluation  of  spread(ei;  x,y.€2)  proceeds  as  follows.  The  expression 
ei  is  evaluated  to  obtain  a  pair  (  Vi,V2  ).  Then  wj  is  substituted  for  i  and  vj  for  y  during  the 
evaluation  of  €2-  The  projections  are  of  course  redundant,  as  they  are  definable  from  spread,  but 
the  current  version  of  Elf  does  not  include  a  definition  facility,  so  they  are  included  in  the  language 
for  the  sake  of  program  readability  and  the  simplicity  of  the  metatheoretical  correctness  proofs. 

A  disjoint  union  type  Ti  |  T2  corresponds  to  a  disjunction  A  y  B,  where  ti  corresponds  to  A  and 
T2  to  B.  The  left  and  right  injections  ini  and  inr  are  extracted  from  the  disjunction  introduction 
rules,  and  the  decide  destructor  from  disjunction  elimination. 

A  function  type  may  correspond  to  an  implication  or  a  universal  quantification.  When  ti  ^  T2 
corresponds  to  A  D  B,  Ti  corresponds  to  A  and  T2  to  B.  When  it  corresponds  to  Vi .  A,  Ti  cor¬ 
responds  to  the  sort  of  x  (the  same  considerations  apply  here  as  for  3x  .A)  and  T2  to  B.  We  use 
lam  to  express  functional  abstraction  and  app  to  express  application  in  order  to  distinguish  them 
from  LF  functional  abstraction  and  application.  A  lam-abstraction  is  extracted  from  the  intro¬ 
duction  rule  for  implication  or  universal  quantification,  and  an  application  from  the  corresponding 
eliminations.  The  nat  Jnd  constructor  permits  the  definition  of  primitive  recursive  functions  and 
is  extracted  from  inductive  proofs. 

The  type  void  corresponds  to  absurdity  (falsehood).  For  a  negation  ->A  there  is  a  corresponding 
type  T  void  where  r  corresponds  to  A;  we  extract  a  function  of  this  type  from  the  rule  of  negation 
introduction.  There  is  a  redundancy  in  our  object  logic  definition  in  that  negation  is  definable  in 
terms  of  implication  and  absurdity.  Like  fst  and  snd,  it  is  included  for  notational  convenience  in 
the  absence  of  a  definition  facility  in  the  Elf  language.  The  extraction  process  collapses  the  two 
notations  at  the  level  of  types:  the  term  extracted  from  a  proof  of  -lA  has  the  same  type  as  the  term 
extracted  from  a  proof  of  A  D  ±.  Such  proofs  can  arise  only  from  the  use  of  negative  assumptions 
or  axioms.  Our  simple  system  contains  only  one  negative  axiom  schema  AXO.  For  an  instance  of 
the  schema  the  extraction  procedure  extracts  neg  with  object  type  t  void  (for  any  object  type 
r).  The  constructor  any  is  used  in  extractions  from  the  rule  of  falsehood  elimination.  This  rule 
allows  an  arbitrary  proposition  C  to  be  inferred  from  a  proof  of  absurdity.  Correspondingly,  the 
object  type  inference  system  allows  an  arbitrary  type  to  be  inferred  for  a  term  of  the  form  any(e) 
if  e  has  type  void.  Since  there  is  no  closed  proof  of  absurdity  in  a  consistent  logic,  evaluation  of 
a  term  of  the  form  any(c)  represents  an  error.  The  operational  semantics  models  this  error  by  a 
(finite)  failure  to  evaluate.  There  is  no  evaluation  rule  for  the  constructor  any,  and  an  Elf  query 
of  the  form  ?-  aval  (any  M)  V  will  terminate  with  failure.  Operationally  this  failure  to  evaluate 
is  distinct  from  the  nontermination  of  a  query  like  ?-  eval  (app  (lam  [x]  app  x  x)  (lam  [x] 
app  X  x))  V.  But  declaratively  both  failures  are  equivalent:  there  is  no  evaluation  deduction  that 
inhabits  the  type  of  either  query. 

The  type  atom  contains  one  element  axiom  and  corresponds  to  equality  assertions.  This  is  a 
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somewhat  arbitrary  choice  as  there  is  no  computational  content  to  a  proof  of  equality;  indeed  in 
Kleene-style  definitions  of  realizability  in  the  domain  of  Heyting  arithmetic  any  number  will  serve 
as  a  realizor  of  an  equality.  The  types  atom  and  unit  are  isomorphic  and  will  be  collapsed  together 
when  we  define  a  more  efficient  version  of  extraction. 

As  there  are  no  new  principles  involved  in  the  encoding  of  the  syntax  of  programs  and  types 
in  LF,  we  show  only  its  implementation  in  Elf  (figure  2.7).  Again,  constructors  with  multiple 
arguments  are  curried,  and  higher-order  abstract  syntax  is  used  for  the  binding  constructors  lam, 
nat  Jnd,  spread,  and  decide. 

We  represent  the  types  of  our  programming  language  explicitly  as  LF  object-level  terms.  Thus 
we  define  a  syntactic  category  tp  of  program  types  ais  well  as  the  syntactic  category  term  of 
program  terms.  Types  are  associated  to  terms  by  the  type  inference  system  presented  below. 
The  representation  of  types  by  LF  objects  is  convenient  for  codifying  the  correspondence  between 
propositions  of  the  object  logic  and  types  of  programs  in  terms  of  a  type  extraction  system. 


Operational  semantics 

We  give  a  call-by-value  operational  semantics  for  the  language  as  a  set  of  inference  rules  (fig¬ 
ure  2.8)  defining  a  judgment  e  v  (e  evaluates  to  v).  This  is  a  natural  semantics  in  the  style  of 
Kahn  [Kah87].  The  choice  of  call-by-value  as  opposed  to  caU-by-name  is  an  arbitrary  one,  although 
it  does  simplify  translation  into  ML,  which  we  have  done  for  some  extracted  programs. 

We  show  the  Elf  implementation  of  the  semantics  in  figure  2.9.  This  encoding  is  the  first 
instance  of  an  Elf  signature  used  for  search,  i.e.,  a  program  as  opposed  to  a  language  definition. 
We  think  of  the  family  eval  primarily  as  representing  a  judgment  rather  than  a  syntactic  category. 
However,  the  signature  also  represents  the  syntactic  category  of  evaluation  deductions,  and  the 
internalized  metatheory  of  Chapter  3  exploits  this  representation.  For  the  purposes  of  introducing 
simple  programming  in  Elf  it  is  easier  to  first  view  the  signature  as  a  Prolog-like  program.  A 
declaration  such  as 

ev_s  :  eval  (s  M)  (s  V)  <-  eval  M  V. 


can  be  read  as  a  Prolog-like  rule,  with  the  backwards  arrow  <-  playing  the  role  of  Prolog’s  :  - 
syntax.  In  the  LF  language,  this  declaration  is  equivalent  to 

ev-s:  HM  :term .  HFiterm .  eval  MV  — ►  eval  (s(M))  (s(y)) 

This  declares  evjs  as  a  constructor  in  the  same  way  as  the  declarations  we  have  dealt  with  heretofore. 
But  operationally,  it  is  a  constructor  available  to  the  Elf  search  mechanism  as  it  constructs  a  proof 
of  a  judgment,  and  so  it  acts  as  a  logic- programming  rule. 

Examination  of  the  clauses  for  applications  reveals  the  inefficiency  of  this  implementation  due  to 
the  backtracking  and  consequent  repeated  evaluation  of  H  when  evaluating  app  M  N.  Nevertheless 
the  signature  does  define  an  operational  interpreter  and  its  structure  is  suitable  for  the  partially 
internalized  metatheory  of  chapter  3. 
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tp  :  type, 
term  :  type. 

arrow  :  tp  ->  tp  ->  tp. 

app  :  term  ->  term  ->  term, 
lam  :  (term  ->  term)  ->  term. 

xmit  :  tp. 

\mity  :  term. 

nat  :  tp. 

0  :  term, 
s  :  term  ->  term. 

nat_ind  :  term  ->  (term  ->  term  ->  term)  ->  term. 

*  :  tp  ->  tp  ->  tp. 

pair  :  term  ->  term  ->  term, 
fst  :  term  ->  term, 

snd  :  term  ->  term. 

spread  :  term  ->  (term  ->  term  ->  term)  ->  term. 

I  :  tp  ->  tp  ->  tp. 
ini  :  term  ->  term, 

inr  :  term  ->  term. 

decide  :  term  ->  (term  ->  term)  ->  (term  ->  term)  ->  term. 

void  :  tp. 

any  :  term  ->  term. 

neg  :  term. 

atom  :  tp. 

Euciom  :  term. 


Figure  2.7:  Elf  encoding  of  the  syntax  of  program  expressions  and  types 
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0^0 


s(e)  s(t;) 


ei  ►  Vi  62  V2 

(  ei,C2  )  <-♦  {  VuV2  ) 


■  ev-pair 


ei’-*{vuV2)  [v\/x][v2ly]e2'-^v 

spread(ei ;  x,y  .62)  v 


ev-spread 


e  <—  ( ) 
fst(e)  ►  vi 


£<->■  (Vi,V2) 
snd(e)  V2 


ev-snd 


inl(e)  «-►  inl(t;) 


inr(e)  ►  mr(t;) 


61  «-►  inl(t;i)  [vi/x]62  ’-*■  v  ei  mr(t;i)  bi/*]e3  ‘-+  r 


decide(ei ;  x  .62',  x  .63)  v 


■  ev-dec-l 


decide(ei;  x.62',  x.ea)'— ‘V 


ev-dec-r 


ei'-flamx.e  62 V2  [v2lx]e<-*v 

- ev-lam  - ev-app-lam 

lamx.e  lamx.e  app(ei,e2) v 


nat_ind(ei;  x,j/.e2)  *— ►  nat  jnd(ei-,  x,y.e2) 


61  nat  jnd(e^;  x,y.e,)  62  <— ►  0  v 

app(ei,e2)  v 


■  ev-pr-z 


Cl  <->-natand(ej;  x,y.e,)  62  <-►  s(t;2)  app((nat-ind(e^;  x,y .e,)),i;2) ^3  [vzAlba/yJe,  « 

app(ei,e2)  <-+t; 


.  ev-pr-s 


()--() 


ev-unit 


•  ev-neg 


axiom  ►  axiom 


neg neg 


Figure  2.8:  Natural  semantics  for  a  functional  programming  language 
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eval  :  term  ->  term  ->  type. 
ev.O  :  eval  0  0. 

ev_8  :  eval  (s  M)  (s  V)  <-  eval  M  V. 

ev.pair  :  eval  (pair  M  N)  (pair  V  V’)  <-  eval  M  V 
ev.spread  :  eval  (spread  H  N)  V 

<-  eval  M  (pair  VI  V2) 

<-  eval  (N  VI  V2)  V. 

ev_fst  :  eval  (fat  M)  VI  <-  eval  M  (pair  VI  V2) . 

ev.snd  :  eval  (and  M)  V2  <-  eval  H  (pair  VI  V2) . 

ev.in!"  :  eval  (ini  M)  (ini  V)  <-  eval  M  V. 

ev_inr  :  eval  (inr  M)  (inr  V)  <-  eval  M  V. 

ev.dec.l  :  eval  (decide  M  N1  Nr)  V 
<-  eval  M  (ini  V*) 

<-  eval  (N1  V’)  V. 
ev_dec_r  :  eval  (decide  M  N1  Nr)  V 
<-  eval  M  (inr  V’) 

<-  eval  (Nr  V')  V. 

ev.lam  :  eval  (lam  H)  (lam  M) . 
ev.app.lam  :  eval  (app  H  N)  V 
<-  eval  H  (lam  M’) 

<-  eval  N  VI 
<-  eval  (M’  VI)  V. 

ev_pr  :  eval  (nat.ind  Mz  Ms)  (nat.ind  Mz  Ms) . 
ev_pr_z  :  eval  (app  M  N)  V 

<-  eval  M  (nat.ind  Mz  Ms) 

<-  eval  N  z 
<-  eval  Mz  V. 

ev_pr_8  ;  eval  (app  M  N)  V 

<-  eval  M  (nat.ind  Mz  Ms) 

<-  eval  N  (s  N’) 

<-  eval  (app  (nat.ind  Mz  Ms)  N’)  M’ 

<-  eval  (Ms  N'  M’)  V. 

ev.unity  :  eval  unity  unity, 
ev.axiom  :  eval  aixiom  axiom, 
ev.neg  :  eval  neg  neg. 


<-  eval  N  V’ . 


Figure  2.9:  CaJl-by-value  natural  semantics  in  Elf 
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Type  inference  system 

In  our  language  types  are  external  to  the  language  of  programs,  and  the  type  of  a  program  expression 
is  determined  by  an  inference  system,  or  type  assignment  system.  In  order  to  distinguish  this  object- 
level  notion  of  type  from  LF  typing,  we  use  the  notation  e  6  r  to  express  the  typing  judgment 
defined  by  this  inference  system.  A  notion  of  a  context  that  assigns  types  to  free  variables  of  an 
expression  is  needed. 

Contexts  F  •  |  r,a;  6  r 

We  adopt  the  convention  that  a  variable  may  be  declared  at  most  once  in  any  context;  thus  r(i) 
may  be  written  for  the  unique  type  assigned  to  x  by  the  context  F.  The  typing  judgment  is  F  h  e  €  r 
(read;  in  context  F  the  expression  e  has  type  t). 

Figure  2.10  gives  a  deductive  system  defining  this  judgment. 

The  implementation  of  this  system  in  Elf  (Figure  2.11)  depends  on  the  use  of  assumptions  to 
represent  a  context.  Instead  of  declaring  a  type  context  and  a  judgment  of  :  context  ->  term 
->  tp  ->  type,  we  declare  the  judgment  of  :  term  ->  tp  ->  type.  To  model  the  addition  of  a 
type  assignment  to  the  current  context,  the  Elf  program  makes  a  typing  assumption.  For  example, 
the  typing  rule  for  A-abstraction  is: 


F,  X  €  ri  h  e  6  r2 

- tp-lam 

F  I-  lam  X .  e  e  n  =>  r2 


The  corresponding  Elf  rule  is: 

tp.lam  :  of  (lam  M)  (arrow  A  B) 

<-  {x:term}  of  x  A  ->  of  (M  x)  B. 


The  operational  semantics  of  the  Elf  interpreter  models  the  required  treatment  of  contexts:  upon 
encountering  the  subgoaJ 

{x:term}  of  x  A  ->  of  (M  x)  B 

the  interpreter  creates  a  new  parameter  x  (modelling  the  convention  that  a  variable  may  occur 
at  most  once  in  a  context)  and  adds  the  judgment  of  x  A  to  its  stock  of  rules.  It  then  searches 
for  a  deduction  of  a  type  assignment  for  (the  normal  form  of)  the  term  (M  x) .  When  the  search 
reaches  a  subgoal  of  x  C  for  some  type  C,  the  assumption  of  x  A  is  used  to  supply  a  type  for  the 
parameter  x.  This  models  the  type  assignment  rule  for  variables: 

F(x)  =  r 

- tp-var 

F  h  X  €  T 

The  type  assignment  system  supports  a  form  of  polymorphism  sufficient  for  expressing  ML-style 
let-polymorphism,  although  we  do  not  exploit  this  capability.  In  the  implementation  a  polymor¬ 
phic  type  appears  as  an  LF  object  of  type  tp  containing  Elf  logic  variables,  which  are  subject  to 
instantiation.  An  example  is  the  identity  function  lamx  .x,  which  is  assigned  the  type  r  r  for 
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r  h  0  G  nat 


r  h  6i  G  ri  r  t-  62  G  t-2 

r  I-  (  ei,€2  )  G  ri  X  r2 


r  H  e  G  nat 
r  I-  s(e)  G  nat 


r  t-  e  G  ri  X  r2 
r  h  f8t(e)  G  Ti 


tp-fst 


r  h  6  G  ri  X  r2 
r  h  snd(e)  G  t2 


tp-snd 


r  I-  ei  G  n  X  r2  r,  a:  G  Ti ,  j/  G  r2  h  62  G  r 
r  f- spread(ei;  x,y.e2)6T 


tp-spread 


r  h  6  G  Ti 

r  I-  inl(6)  G  n  I  r2 


r  I-  6  G  7-2 
r  t-  inr(6)  G  n  I  r2 


tp-inr 


r  h  6i  G  Ti  1  r2  r,  X  G  n  h  62  G  r  T,  x  G  7-2  h  63  G  r 
r  f-  decide(6i;  x  .62;  x  .63)  G  r 


tp-dec 


r,  X  G  Ti  H  6  G  r2 
r  I-  lam  X .  6  G  7-1  r2 


tp-lam 


r  I-  ei  G  Ti  =>•  T2  r  h  62  G  Ti 
r  I-  app(6i,62)  G  T2 


tp-app 


r  h  61  G  7-  r,x  G  nat,t/ G  r  h  62  G  T 

- tp-prec  - -  tp-unit 

r  H  natJnd(6i;  x,y.62)  G  nat  t  F  h  ()  g  unit 


r  I-  6  G  void 
r  h  any(6)  G  r 


tp-any 


r  h  axiom  G  atom 


tp- axiom 


r  h  neg  G  T  =>  void 


tp-neg 


r(x)  =  r 

r  I-  X  G  r 


tp-var 


Figure  2.10:  Type  assignment  system  for  the  core  language 
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of  :  term  ->  tp  ->  type. 
tp_0  :  of  0  nat. 

tp_8  :  of  (s  M)  nat  <-  of  M  nat. 

tp.pair  :  of  (pair  M  N)  (*  A  B)  <-  of  M  A  <-  of  N  B. 
tp_f St  :  of  (f St  M)  A  <-  of  M  (*  A  B) . 

tp_snd  :  of  (snd  M)  B  <-  of  M  (*  A  B) . 

tp.spread  :  of  (spread  Mpr  N)  C 
<-  of  Mpr  (*  A  B) 

<-  {x}  of  X  A  ->  {y}  of  y  B  ->  of  (N  x  y)  C. 

tp.inl  :  {B>  of  (ini  M)  (|  A  B)  <-  of  M  A. 

tp.inr  :  {A}  of  (inr  M)  (I  A  B)  <-  of  M  B. 

tp.dec  :  of  (decide  N  N1  Nr)  C 
<-  of  M  (I  A  B) 

<-  ({x:term}  of  x  A  ->  of  (N1  x)  C) 

<-  (•Cx:term}  of  x  B  ->  of  (Nr  x)  C) . 

tp.lam  :  of  (lam  M)  (arrow  A  B) 

<-  {x:term}  of  x  A  ->  of  (M  x)  B. 
tp.app  :  of  (app  M  N)  B  <-  of  M  (arrow  A  B)  <-  of  N  A. 

tp.prec  :  of  (nat.ind  Mz  Ms)  (arrow  nat  A) 

<-  of  Mz  A 

<-  ({x}  of  X  nat  ->  {y}  of  y  A  ->  of  (Ms  x  y)  A) . 

tp_\mity  :  of  unity  unit, 
tp.axiom  :  of  axiom  atom. 

tp.any  :  {A}  of  (any  M)  A  <-  of  M  void, 
tp.neg  :  {A}  of  neg  (arrow  A  void) . 


Figure  2.11:  Elf  implementation  of  type  assignment 
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K"  "P  i  p'f  ^ 

Proof  V - — - -  Proposition  $ 


huiT’^M 


h  ti; :  $  r 


Program  M  — ^  ^  ^  ^ - -Type  r 

Figure  2.12:  Elf  implementation  of  proofs-as-programs 


any  type  r.  When  presented  with  the  query  of  (lam  [x]  x)  T,  Elf  succeeds  with  a  substitution 
of  the  form  T  =  (arrow  A  A)  -  A  is  an  internally  created  logic  variable;  the  substitution  constrains 
any  ground  term  found  fo'  T  during  further  search  to  be  a  representation  of  an  object  type  r  =>•  r 
for  some  r. 


2.3.2  Extraction 

In  this  section  we  define  judgments  4  and  for  program  and  type  extraction;  this  completes  an 
implementation  of  the  proofs-as-programs  view  of  constructive  logic,  as  shown  in  Figure  2.12.  At 
each  vertex  of  the  diagram  is  an  LF  object  encoding  a  proof,  proposition,  program,  or  (object 
programming  language)  type.  These  objects  are  related  by  LF  typing  assertions  -  the  turnstile 
I-  here  means  derivability  in  LF.  The  minuscules  tt,  v,  and  w  should  be  read  existentially:  they 
are  the  terms  found  by  the  Elf  interpreter  as  it  searches  for  proofs  of  the  judgments  .(1.,  and 
€.  We  have  already  described  the  judgments  pf  (proof  well-formedness)  and  €  (object  language 
type  assignment).  The  judgments  (read:  the  program  M  is  extracted  from  the  proof  V) 

and  $  4*  T  (read:  the  type  r  is  extracted  from  the  proposition  $)  are  defined  so  that  whenever 
h  :  pf  $  and  \-  u  :  V^M  and  I-  in  :  then  h  r  :  Af  €  r.  (However,  there  may  be  other 

types  that  can  be  inferred  for  M;  for  example,  for  lam  x .  x  we  can  infer  Af  €  t  =►  r  for  any  type 
r.)  Moreover  if  u  :  Vi^M  and  x  :  M  V  then  there  is  a  proof  V'  such  that  h  V  :  pf  $ 
and  V-  x'  -.V These  results  are  proved  and  the  proofs  partially  internalized  as  Elf  programs  in 
Chapter  3. 

The  program  extraction  judgment  implicitly  defines  a  kind  of  realizability  interpretation,  if 
realizability  is  taken  to  interpret  sentences  of  the  object  logic  in  the  domain  of  expressions  of  the 
programming  language.  The  deductive  system  for  establishing  the  judgment  corresponds  in  its 
essentials  to  axiomatic  characterizations  of  realizability  such  as  that  found  in  Troelstra  [TvD88]. 
However,  the  core  object  logic  is  too  weak  to  internalize  the  realizability  relation  as  is  done  in  other 
systems.  We  leave  it  implicit  and  rely  on  reasoning  at  the  metaJevel  to  establish  correctness. 

The  encodings  of  proofs  and  functional  programs  as  LF  objects  facilitate  the  treatment  of  type 
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T  4'  unit 


xtT 


- xt± 

±  .U.'  void 


A4‘r 

- xt-i 

-•i4  r  =>  void 


- XtA 

A  A  B  i^*Ti  X  T2 


Ai^^Ti  B^‘r2 

- xtv 

A  V  I  T2 


- XtD 

A  D  B  Ti  T2 


Ai^^T 

- xtv 

'ix  .Ai^'‘  nat  =>•  r 


/1^‘r 

- Xt3 

3i .  >l  -1).*  nat  X  T 


- xt= 

ti  =  <2  -IJ-*  atom 


Figure  2.13:  Type  extraction 


and  program  extraction  as  deductive  systems.  We  first  give  naive  formulations  of  these  systems  that 
extract  types  that  mimic  closely  the  structure  of  propositions  and  programs  that  mimic  closely  the 
structure  of  proofs.  For  the  pure  first-order  logic  fragment  of  our  object  logic  (without  arithmetic) 
the  rules  of  the  type  extraction  system  are  precisely  congruent  to  the  syntax  of  propositions;  the 
rules  of  the  program  extraction  system  are  congruent  to  the  inference  rules  of  the  logic.  Then 
we  discuss  the  distinction  between  proofs  with  computational  content  and  those  without  it,  and 
present  a  modification  of  extraction  that  removes  computationally  useless  subterms  of  the  extracted 
program. 


Naive  extraction 

The  judgment  relates  propositions  of  FOL  and  types  of  the  programming  language  as  explained 
in  section  2.3.1.  It  is  defined  by  the  rules  of  Figure  2.13;  its  translation  into  Elf  is  straightforward 
and  does  not  involve  any  new  principles. 

The  judgment  ().  relates  natural  deduction  FOL  proofs  and  expressions  of  the  programming 
language.  An  auxiliary  judgment  .0'  establishes  the  corresponding  relation  between  individual 
terms  of  the  logic  and  programming-language  expressions  (in  our  simple  system,  these  must  be 
terms  representing  natural  numbers). 

The  rules  for  J)  work  by  a  straightforward  case  analysis  of  the  last  inference  in  the  proof  under 
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consideration;  therefore  we  present  them  in  terms  of  proof  schemas.  A  schema  of  the  form 


matches  an  object  proof  ending  in  a  formula  A;  any  variables  free  in  A  may  also  occur  free  in  V. 

Since  .1).  is  defined  inductively  over  the  structure  of  proof  objects,  which  contain  discharged 
assumptions  and  bound  individual  variables,  a  context  of  extraction  assignments  for  assumptions 
and  individuals  is  needed.  Variables  for  individuals  axe  part  of  the  logical  language;  they  are  bound 
by  the  quantifiers.  Variables  for  discharged  assumptions  are  part  of  the  proof  language  and  are 
bound  by  the  inference  rules  that  discharge  them  (31,  VE,  3E,  and  IND).  We  represent  this  context 
as  a  pair  {  r,A  ),  where  F  is  a  sequence  of  assignments  for  individual  variables  and  A  a 

sequence  of  assignments  ^  As  usual  we  stipulate  that  all  variables  in  a  context  are  distinct. 

Thus  we  may  treat  a  context  as  a  pair  of  partial  functions  on  variables,  and  write  r(x)  =  x'  when 


z  x'  is  an  extraction  assignment  in  F,  and  A  J  =  p'  when  ^  (l-p'  is  an  extraction  assignment 

in  A.  We  extend  this  convention  in  the  obvious  way  and  also  write  {  F,A  )(z)  =  x'.  We  write 
(  (F,i.(|.*  x'),  A  )  for  the  result  of  extending  (  F,A  )  with  the  term  extraction  assignment  x(J.*x', 
and 

{ r,(A,[^»p') ) 

for  the  result  of  extending  (  F,  A  )  with  the  proof  extraction  assignment  ^  (Ip'. 

Extraction  assignments  for  assumptions  lead  to  schemas  of  the  form 


This  matches  a  proof  fragment  that  depends  on  an  assumption  A  where  p  is  the  (hypothetical) 
proof  of  A.  The  context  (  F,  A  )  contains  an  extraction  assignment  p'  for  p. 

The  full  form  of  the  extraction  judgment  is 


(F,A)l-|^()e 

(read:  in  the  context  (  F,  A  ),  e  represents  the  computational  content  of  the  proof  V  oi  A.) 

The  implementation  of  extraction  in  Elf  uses  the  same  technique  for  representing  the  context 
as  in  the  implementation  of  type  inference.  Instead  of  representing  it  explicitly,  we  introduce 
parameters  and  assumptions  during  the  search  process.  Thus  the  Elf  declaration  of  the  extraction 
judgment  encodes  a  relation  on  two  objects  rather  than  three,  leaving  the  context  implicit: 


extract  :  |-  A  ->  term  ->  type, 
extract.tm  :  i  ->  term  ->  type. 
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- —  ex-zero 

r  h  zero^'  0 


- ^ - ex-succ 

r  h  succ  t  s(e) 


Figure  2.14:  Program  extraction  from  individual  terms 


r(a:)  =  x' 

- ex-ivar 


(r,A}h 


i^p' 


ex-pvar 


Figure  2.15:  Extraction  for  individual  and  proof  variables 

The  full  deductive  system  for  program  extraction  from  individual  terms  and  proofs  is  presented 
in  Figures  2.14  through  2.19.  Extraction  from  individuals  is  straightforward  in  the  limited  system 
under  consideration  here.  The  inference  rules  for  extraction  from  proofs  imitate  the  structure  of 
the  natural  deduction  inference  rules  (compare  Figure  2.2).  We  explain  a  few  characteristic  rules 
in  detail  and  discuss  their  implementation  in  Elf. 

The  simplest  case  for  extraction  is  a  proof  in  the  object  logic  consisting  of  an  inference  rule  with 
no  premises  (essentially  an  axiom,  though  natural  deduction  does  not  distinguish  between  axioms 
and  inference  rules).  An  example  is: 


—  TI 

T 


The  corresponding  extraction  rule  has  the  same  structure: 


(r,A)i- 


xT 


Its  encoding  in  Elf  is  straightforward: 
ex_truei  :  extract  truei  unity. 


Recall  that  truei  has  been  declared  as  an  object  of  type  I  -  true;  it  represents  the  proof  of  T 
in  the  extraction  deduction.  Similarly,  \mity  is  an  object  of  type  term  representing  the  program 
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Figure  2.16:  Program  extraction,  logical  rules,  part  1 
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Figure  2.17:  Program  extraction,  logical  rules,  part  2 
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Figure  2.18:  Program  extraction,  logical  rules,  part  3 
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Figure  2.19:  Program  extraction,  arithmetic  rules 
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expression  ().  The  implicit  propositional  argument  true  of  the  extract  judgment  is  reconstructed 
by  Elf  during  the  type  checking  of  this  rule  from  the  type  of  truei. 

In  the  case  of  a  proof  ending  in  an  inference  rule  that  has  premises,  but  neither  discharges  an 
assumption  nor  binds  an  individual  variable,  extraction  simply  descends  through  the  proof,  extract¬ 
ing  program  expressions  for  the  subproof(s),  and  applies  the  appropriate  constructor  or  destructor 
to  the  resulting  program  expression.  To  express  this  as  an  inference  rule,  we  use  schematic  variables 
for  subproofs  -  these  are  distinct  from  the  bound  variables  associated  with  assumptions.  In  the 
notation 


V 

A 


V  stands  for  the  proof  with  conclusion  ^4. 

Extraction  from  the  rule  of  conjunction  introduction  is  an  example: 


The  encoding  in  Elf  is  again  straightforward,  simply  introducing  two  subgoals: 

ex.andi  :  extract  (andi  PI  P2)  (pair  Ml  M2) 

<-  extract  PI  Ml  <-  extract  P2  M2. 


Again  term  reconstruction  permits  the  omission  of  the  impUcit  propositional  argument,  since  andi 
has  been  declared  with  type  |-  A  ->  |-  B  ->  |-  (and  A  B). 

The  Dl  rule  is  a  simple  example  of  the  treatment  of  the  discharge  of  assumptions  by  adding  an 
extraction  assignment  to  the  context  (  r,A  ). 


P 

A 


The  assignment 
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associates  the  hypothetical  proof  p  of  the  assumption  A  with  the  program  variable  p'  bound  by 
the  lam-abstraction.  As  a  result,  when  a  goal  of  extracting  an  expression  from  p  occurs  in  the 
deduction,  the  rule  ex-pvar  for  proof  variables  applies. 

The  Elf  implementation  models  the  context  {  r,A  )  at  the  meta-level  by  introducing  assump¬ 
tions.  The  Elf  encoding  of  the  rule  xdI  is: 

ex.impliesi  :  extract  (impliesi  P)  (lam  M) 

<-  {p:|-  A}  {p’:term}  extract  p  p’  ->  extract  (P  p)  (M  p’). 

In  contrast  to  the  assumptions  introduced  in  the  implementation  of  the  type  assignment  system, 
which  quantify  over  one  parameter  representing  a  bound  program  variable,  here  we  quantify  over 
two  parameters:  p  represents  a  bound  proof  variable  and  p  *  represents  a  bound  program  variable. 

The  treatment  of  bound  individual  variables  in  proofs  is  much  the  same,  but  the  extraction 
assignment  added  to  the  context  is  modelled  as  the  extract-tm  judgment.  An  example  is  the 
extraction  rule  for  VI: 


((r,xrx'),A}h 


•XVI 


<r,A)i- 


il-  lam  x' .  e 


The  Elf  implementation  is: 

ex_foralli  :  extract  (foralli  P)  (lam  H) 

<-  {x:i}  {x’:term}  (extract_tm  x  x’  ->  extract  (P  x)  (M  x’)). 


Program  simplification  during  extraction 

As  noted  above,  naive  extraction  results  in  a  program  containing  many  subterms  that  carry  no 
computationally  useful  information.  Intuitively  speaking,  this  is  because  the  only  lc>gicai  formulas 
whose  proofs  involve  choice  are  disjunctions  and  existential  quantifications.  A  proof  of  4  V  B 
provides  a  method  for  deciding  whether  A  or  5  holds;  a  proof  of  3x .  A  provides  a  method  for  finding 
a  particular  natural  number  t  (the  “witness”)  such  that  [t/x]A  holds.  The  inference  rules  for  the 
other  logical  connectives  merely  combine  the  proofs  of  their  components  in  an  appropriate  way.  If 
the  components  are  void  of  computational  content,  so  is  the  resulting  proof.  We  call  formulas  free 
of  3  and  V  uninformative.  By  extension  we  call  their  proofs,  the  object  types  extracted  from  them, 
and  the  programs  extracted  from  the  proofs  uninformative  as  well. 

The  work  described  here  is  an  adaptation  to  the  Elf  setting  of  the  basic  ideas  of  modified 
realizability  developed  for  the  Calculus  of  Constructions  by  Paulin- Mohr ing  [PM89]  which  in  turn 
takes  from  the  PX  system  [Hay90]  the  idea  of  syntactically  defining  a  class  of  content-free  terms. 
Sasaki  [Sas86]  develops  these  ideas  for  Nuprl.  The  negative  formulas  of  Schwichtenberg  [Sch82], 
[Sch85]  are  used  in  a  similar  way  to  decrease  the  complexity  of  realizing  terms. 
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We  define  extraction  procedures  for  types  and  programs  that  simplify  the  extracted  terms  to 
remove  uninformative  subterms  while  retaining  computationally  useful  information.  As  for  naive 
extraction,  the  extracted  programs  are  well-typed  and  the  extracted  types  can  be  inferred  for  them 
by  the  type  inference  system  of  Figure  2.10. 

In  order  to  preserve  well-typedness,  we  distinguish  between  positive  and  negative  uninformative 
formulas. 

The  positive  uninformative  formulas  are  the  ^am)p[Har60]  formulas: 

Harrop  formulas  H  ::=  T  j  =  <2  ]  H  A  H  |  'ix  .H  \  A  D  H 
where  A  is  any  formula. 

For  these  formulas  we  extract  the  unit  element  ().  Programs  can  be  further  simplified  by  noting 
that  an  expression  extracted  from  A  D  B,  where  A  is  Harrop,  will  have  type  unit  r,  where  r 
is  the  type  extracted  from  B.  But  this  type  carries  no  more  information  than  r  itself,  so  we  may 
as  well  extract  a  term  of  type  r  instead.  Similar  considerations  apply  to  extraction  from  A  A  B 
where  either  A  or  5  is  Harrop. 

As  a  small  example,  consider  a  program  to  compute  the  predecessor,  extracted  from  a  proof  of 
'ix  .X  =  zero  V  (3t/ . x  =  succ  (j/)).  The  equalities  are  Harrop  formulas;  their  proofs  are  represented 
in  the  program  by  the  special  constant  axiom. 

nat  Jnd(  (inl(axiom)) ;  x,u  .  inr({  x, axiom  ))) 

The  type  of  this  expression  is  nat  =>  (atom  |  (nat  x  atom)).  The  occurrences  of  the  type  atom 
represent  the  uninformative  parts  of  the  proof. 

When  the  proof  is  simplified  by  extracting  unit  terms  ()  for  Harrop  formulas,  the  resulting 
program  has  type  nat  =>  (unit  |  nat).  The  simplification  removes  the  purely  logical  part  of  the 
proof,  leaving  the  left  and  right  injections  and  the  witness,  which  is  the  predecessor  value  we  want 
to  compute. 

nat  Jnd(  inl(()) ;  x^v.  inr(x)) 

The  negative  (uninformative)  formulas  are 

Negative  formulas  JV  ::=  J.  |  -lA 

where  A  is  any  formula. 

These  are  treated  separately  from  the  Harrop  formulas  because  of  the  intuitionistic  absurdity 
rule  ±E,  which  allows  the  deduction  of  any  formula  from  a  proof  of  ±.  Recall  the  corresponding 
typing  rule: 

r  h  e  €  void  ^ 

- tp-any 

r  I-  any(e)  €  r 

Terms  extracted  from  proofs  of  negations  have  type  r  ^  void;  we  cannot  simply  reduce  these 
to  the  unit  element  ()  if  they  appear  in  any(e),  or  the  result  cannot  be  typed.  Nor  can  we  extract 
an  element  of  type  void  if  the  semantics  of  the  language  is  to  faithfully  reflect  a  consistent  logic. 

Consider  another  predecessor  program,  this  time  extracted  (naively)  from  an  inductive  proof  of 
Vx .  -ix  =  zero  D  3j/ .  x  =  succ  y.  The  absurdity  rule  ±E  occurs  in  the  base  case  of  the  induction. 
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- h-true 

Haxrop  T 


- h-eq 

Harropti  = 


Harrop  A  Harrop  B 
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h-and 


Harrop  A 
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- h-implies 

Harrop  y4  D  B 


Figure  2.20:  Harrop  formulas 


natJnd(lamv.  any(app(u, axiom));  i,p.  lamv.(  i, axiom  )) 

The  extracted  type  is  nat  =>■  (atom  =>  void)  =>  (nat  x  atom).  The  program  subexpression 
of  interest  is  lamv.  any (app(u,  axiom)),  extracted  from  the  base  case  of  the  induction.  The 
component  atom  =>  void  of  the  type  corresponds  to  the  bound  variable  v,  which  (for  the  base 
case)  represents  a  proof  of  -izero  =  zero,  which  is  not  provable  in  a  consistent  system.  Thus  this 
case  returns  a  function  which  it  would  be  an  error  to  apply;  that  is  why  the  function  body  is 
any(app(v,  axiom)),  which  cannot  be  evaluated.  Any  term  that  could  be  bound  to  v  would  have 
no  computational  content,  so  it  is  desirable  to  eliminate  it  altogether.  But  we  must  still  insure  that 
an  error  is  signalled  in  the  base  case,  which  would  not  happen  if  we  simplified  the  subexpression 
to  ();  and  any(())  is  not  typable.  Instead  we  extract  the  constant  neg  for  any  proof  of  a  negative 
formula,  and  app(neg,  ())  for  any  proof  of  ±,  so  the  simplified  subexpression  is  any(app(neg,  ())), 
which  is  typable.  The  whole  simplified  program  is: 

nat Jnd(any(app(neg,()));  x,p.x) 
with  type  nat  nat. 

As  before,  we  give  the  implementation  of  simplification  during  extraction  of  types  and  programs 
in  the  form  of  deductive  systems.  We  define  the  following  judgments: 

1.  Harrop  A  (A  is  a  Harrop  formula):  Figure  2.20 

2.  Uninf  A  (A  is  an  uninformative  formula):  Figure  2.21 

3.  Inf  A  (A  is  an  informative  formula):  Figure  2.22 

4.  A  r  (type  extraction/simplification):  Figure  2.23 
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Figure  2.21:  Uninformative  formulas 
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Figure  2.22:  Informative  formulas 
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Figure  2.23:  Type  extraction/simplification 
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Figure  2.24:  Program  extraction/simplification  for  uninformative  proofs 

5.  A-lJ-jC  (program  extraction/simplification):  Figures  2.24,  2.25,  2.26,  and  2.27 

The  first  three  axe  simple  syntactic  properties  of  formulas:  (1)  is  a  straightforward  deductive 
formulation  of  the  grammar  of  Harrop  formulas  given  above;  (2)  defines  uninformative  formulas 
as  formulas  built  up  from  Harrop  and  negative  formulas;  and  (3)  is  the  complement  of  (2).  The 
main  judgments  are  the  extraction/simplification  of  types  and  programs,  guided  by  the  syntactic 
analysis  given  by  the  three  auxiliary  judgments. 

The  deductive  systems  for  both  type  extraction  and  program  extraction  are  modifications  to 
the  naive  extraction. 

In  type  extraction  most  of  the  rules  of  Figure  2.13  are  retained,  but  premises  are  added  to 
them  to  ensure  that  all  subformulas  are  informative.  When  the  whole  formula  is  uninformative 
no  analysis  of  subformulas  is  done;  we  merely  need  to  distinguish  between  Harrop  and  negative 
uninformative  formulas.  For  conjunction,  implication,  and  existential  quantification  extra  rules  are 
added  to  account  for  uninformative  subformulas.  No  special  rule  for  type  extraction  from  equalities 
is  needed  since  they  are  Harrop. 

Program  extraction  is  defined  similarly  although  complications  arise  because  of  the  elimination 
rules  of  the  logic.  Extraction  for  individual  terms  and  for  individual  and  proof  variables  is  defined 
in  the  same  way  as  for  naive  extraction  (Figures  2.14  and  2.15  respectively),  so  we  omit  their 
explicit  definitions.  For  uninformative  formulas  and  the  introduction  rules  of  the  logic,  program 
extraction  has  the  same  form  as  type  extraction.  For  logical  disjunction,  extraction  is  defined  as 
for  the  naive  case.  Even  if  both  A  and  B  are  uninformative,  a  proof  o{  A  y  B  always  contains  at 
least  the  computation  of  which  case  holds,  so  the  extracted  program  expression  must  be  a  left  or 
right  injection  into  a  disjoint  union  type,  although  that  type  may  be  simpler  than  in  the  case  of 
naive  extraction. 
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Figure  2.25:  Program  extraction/simplification,  conjunction  rules 


52 


xsvit 


xsvijj 


XSVE 


Figure  2.26:  Program  extraction/simplification,  disjunction  rules 
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XSDIR 


XSDE 
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Inf  A  { (r,x^*x'),A  )  I- 
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Inf /I  (r,A)h 


V 
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V 

(r,A)i- 

A 

- VI 

Vx.A 

.ll,  lam  x' .  € 

(r,A)h 

'ix.A 

- VE 

XVE 


■U's  app(ei,e2) 


Figure  2.27:  Program  extraction/simplification,  implication  and  universal  quantification  rules 
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ri-U’ei  Inf /I  (r,A}H 


V 

[tlx]A 


■li-a  «2 


XS3I 


UninfA  ri-i^‘e 


V 

V 

(r,A>i- 

[tlx]A 

- 31 

3x  .A 

ci,e2  ) 

<r,A)i- 

[tlx]A 
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3x .  A 
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Figure  2.28:  Program  extraction/simplification,  existential  quantification  and  absurdity  rules 
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Figure  2.29:  Program  extraction/simplification,  induction  rule 


The  elimination  rules  for  conjunction,  implication,  and  existential  quantification  require  checking 
for  uninformative  subformulas  to  avoid  applying  a  destructor  (projection,  function  application,  or 
spread)  inappropriately.  For  the  elimination  of  an  implication  A  D  B,  naive  extraction  yields 
app(ci,C2).  But  we  must  now  account  for  the  possibility  that  ^4  is  uninformative  and  thus  ej  is 
not  a  function;  in  that  case  the  program  to  be  extracted  is  ex  alone.  (If  B  is  Harrop  the  rule 
xsH  of  course  applies.)  The  conjunction  elimination  rules  are  treated  in  an  analogous  way.  Naive 
extraction  for  the  existential  quantifier  elimination  rule  yields  an  expression  spread(ei;  2:1,12  •  ^2) 
where  a;i  is  bound  to  the  witness  term  and  12  to  the  proof  term  during  the  evaluation  of  €2-  But 
if  A  is  uninformative  there  is  no  proof  term,  and  instead  we  extract  app(lamxi  .e2,ei). 

The  rules  xsoIR  (Figure  2.27)  and  xs3EL  (Figure  2.28),  which  deal  with  implication  introduction 
and  existential  elimination  respectively,  have  the  interesting  feature  that  extraction  is  performed 
on  subproofs  containing  proof  variables  for  which  no  extraction  assignment  is  introduced  in  the 
context.  Thus  for  instance  the  rule  xsdIR  can  succeed  only  if 


(r,A>t- 


p 

A 

V 

B 


can  be  deduced  for  arbitrary  p.  At  first  glance  it  might  seem  that  extraction  could  fail  without 
an  assignment  for  p.  But  for  uninformative  formulas  extraction/simplification  does  not  need  to 
examine  the  proof.  As  a  consequence  we  have  the  following: 


Lemma  2.1  (Elimination  of  proofs  of  uninformative  formulas)  //Uninf  A  and  there  is  an  extrac¬ 
tion  deduction 


^::{r,(Ai, 

then  there  is  an  extraction  deduction 


^,p',A2))I- 


£•  ::(r,(Ai,A2))l- 


■dae 
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Proof  2.2  The  proof  is  an  easy  induction  on  the  structure  of  €. 

In  the  cases  where  S  ends  in  xs-",  xs±,  or  xsH,  the  deduction  does  not  depend  on  the  environment. 
If  €  ends  in  extraction  from  a  proof  variable: 


ex-pvar 


there  are  two  cases.  If  5  is  then  B  is  uninformative  and  there  is  an  extraction  deduction  for  B 
ending  in  xs-i,  xs±,  or  xsH.  Otherwise  construct  the  deduction 


(Ai,  A2)  ^ 

B 

)  =  ,' 

(r,(At,A2)}i- 

9 

B 

^9' 

ex-pvar 


The  other  cases  are  easy  inductions  since  every  assumption  in  the  conclusion  of  an  extraction 
deduction  occurs  in  every  subdeduction.  □ 

In  Figure  2.30,  we  show  a  fragment  of  the  Elf  implementation  of  simplifying  extraction.  There 
is  one  feature  of  this  program  that  has  not  appeared  before:  some  dependently-typed  terms  are 
annotated  with  their  types.  The  following  rule  for  extraction  from  an  implication  introduction  is 
an  example: 

exs.implil  :  extract.simp  (iBiplie<-i  (P:  |-  A  ->  |-  B))  M 
<-  uninf  A  <-  inf  B 
<-  {p:  I-  A}  extract.simp  (P  p)  M. 


Here  the  argument  P  of  implies!  is  a  function  from  a  proof  of  some  proposition  A  to  a  proof  of 
some  proposition  B,  and  one  of  the  premises  is  that  A  is  uninformative.  We  annotate  P  with  its 
type  in  order  to  express  this  premise. 

Related  work 

The  use  of  syntactic  criteria  to  detect  formulas  void  of  computational  content  comes  from  the  PX 
system  [Hay90].  The  idea  is  developed  for  the  Calculus  of  Constructions  by  Paulin- Mohring  [PM89] 
and  for  Nuprl  by  Sasaki  [Sas86]. 

Both  PX  and  Constructions  are  stronger  logics  than  ours  in  which  programs  are  terms  of  the 
logic  and  realizability  is  definable  in  the  logic.  This  provides  a  different  basis  for  proving  the 
soundness  of  extraction. 

Unlike  our  extraction  and  Paulin-Mohring’s,  extraction  in  PX  does  not  reduce  a  functional  type 
A  —>■  B  where  A  is  uninformative  (type  0  in  the  terminology  of  PX)  to  the  type  B.  As  a  result  the 
types  of  extracted  terms  retain  more  structure  than  in  our  scheme. 


V 
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extract.simp  :  |-  A  ->  term  ->  type. 

exs.unit  :  extract.simp  (P:  |-  A)  unity  <-  harrop  A. 

exs.implil  :  extract.simp  (impliesi  (P:  |-  A  ->  |-  B))  M 
<-  uninf  A  <-  inf  B 
<-  {p:  |-  A}  extract.simp  (P  p)  M. 

exs.implel  :  extract.simp  (impliese  (P:  |-  (implies  A  B))  Q)  H 
<-  uninf  A  <-  inf  B  <-  extract.simp  P  M. 

exs.andi2  :  extract.simp  (andi  (P:  |-  A)  (Q:  |-  B))  M 
<-  uninf  A  <-  inf  B  <-  extract.simp  Q  M. 

exs.andell  :  extract.simp  (andel  (P  :  |-  (and  A  B)))  H 
<-  inf  A  <-  uninf  B  <-  extract.simp  P  M. 

exs.anderl  :  extract.simp  (ander  (P  :  |-  (and  A  B)))  H 
<-  uninf  A  <-  inf  B  <-  extract.simp  P  M. 

exs.existsil  :  extract.simp  (existsi  A  T  _)  M 

<-  ({x:i}  uninf  (A  x))  <-  extract .tm  T  M. 

exs.existsel  :  extract.simp  (existse  P  (Q:  |-  (exists  A)))  (app  (lam  N)  N) 
<-  ({X:!}  uninf  (A  X)) 

<-  (•CX:i}  {x:term}  extract  .tm  X  x 

->  {p:  I-  (A  X)}  extract.simp  (P  X  p)  (H  x)) 

<-  extract.simp  Q  M. 

exs.existse2  :  extract.simp  (existse  P.min  P.maj)  (spread  N  M) 

<-  (-CX:i}  inf  (A  X)) 

<-  ({X:i}  {x:term}  extract .tm  X  x 

”>  {P:l“  (A  X)}  -Cprterm}  extract.simp  P  p 
->  extract.simp  (P.min  X  P)  (M  x  p)) 

<-  extract.simp  P.maj  N. 


Figure  2.30:  A  fragment  of  program  extraction/simplification  in  Elf 
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In  our  system  extraction  is  defined  for  all  propositions  and  proofs,  whether  informative  or  not. 
In  Constructions  extraction  is  defined  only  for  informative  terms;  but  as  Paulin-Mohring  observes 
it  can  be  defined  for  all  terms  essentially  in  the  same  way  as  in  our  system. 


Chapter  3 

Some  Metatheory 


Some  correctness  properties  of  extraction  can  be  partially  verified  in  Elf  by  formulating  deduction 
transformations  along  the  lines  described  in  [PR92],  [HP92].  As  these  authors  point  out,  the  veri¬ 
fication  technique  is  essentially  that  described  in  [Des86],  but  the  dependent  types  of  LF  eliminate 
the  need  for  explicit  reasoning  about  the  validity  of  the  objects  involved,  and  the  term  and  type 
reconstruction  of  Elf  mechanize  the  management  of  many  details.  We  give  informal  proofs  of  the 
correctness  properties  along  with  their  partial  internalization  in  Elf;  they  cannot  be  completely 
internalized  since  there  is  no  internally  representable  induction  principle  for  LF  signatures. 

The  first  property  of  extraction  we  consider  is  type  soundness:  when  we  extract  a  program 
expression  e  from  a  proof  of  a  proposition  A,  and  we  extract  a  type  r  from  A,  we  want  to  be  able 
to  deduce  e  G  r  in  the  type  assignment  system  of  Figure  2.10. 


Theorem  3.1  (Type  soundness  of  extraction)  For  any  V,  A,  e,  and  t,  if  h 
then  h  e  G  r. 


1)  e  and  h  A  D*  r 


The  second  property  we  consider  is  evaluation  soundness:  when  we  extract  a  program  e  from  a 
proof  V  of  &  proposition  A,  and  e  evaluates  to  v,  we  want  there  to  be  a  proof  V  of  A  from  which 
we  can  extract  v. 


Theorem  3.2  (Evaluation  soundness  of  extraction)  For  any  V,  A,  e,  and  v, 


f-  e  •— >  u  then  there  is  a  proof  V  such  that  H 


iff- 


V 

A 


i^e  and 


Both  type  and  evaluation  soundness  have  proofs  by  straightforward  induction  over  the  structure 
of  extraction  and  evaluation  deductions,  respectively.  These  proofs  construct  formal  deductions  of 
the  required  type  from  given  formal  deductions.  The  dual  nature  of  Elf  signatures  -  which  can 
be  viewed  as  either  logic  programs  or  language  definitions  -  supports  the  direct  expression  of  the 
constructive  parts  of  the  proofs.  Each  case  of  the  induction  is  expressed  as  an  Elf  clause  that  matches 
a  deduction  of  a  part'  ular  shape.  Thus  to  partially  internalize  the  proof  of  type  soundness  we 
formulate  an  Elf  sign;  are  to  translate  deductions  of  extraction  judgments  to  deductions  of  typing 
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assignment  judgments.  The  signatures  that  define  extraction  and  typing  assignment  judgments  are 
viewed  here  as  language  definitions,  although  they  are  also  executable  Elf  programs. 

When  discussing  the  proofs,  we  will  need  to  name  the  formal  deductions  of  extraction,  typing, 
etc.  To  say  that  some  judgment  J  is  derivable,  we  often  write  simply  “J”;  we  write  V  ::  J  when  V 
is  a  deduction  of  the  judgment  J . 

This  chapter  is  organized  as  follows:  first  we  present  a  proof  of  type  soundness  for  naive  ex¬ 
traction,  with  its  partial  formalization  in  Elf.  Then  we  show  how  to  modify  the  proof  for  ex¬ 
traction/simplification.  A  similar  but  briefer  presentation  of  evaluation  soundness  follows.  An 
interesting  feature  of  the  evaluation  soundness  proof  is  that  its  formalization  implements  a  set  of 
reductions  for  intuitionistic  proofs  with  induction. 


3.1  Type  soundness 


The  proof  is  an  induction  on  the  structure  of  the  extraction  deduction.  Since  extraction  deductions 
in  general  depend  on  a  context  of  extraction  assumptions,  we  generalize  the  theorem  accordingly. 
The  proof  must  construct  a  typing  deduction  for  every  extraction  deduction,  so  it  is  necessary  to 
define  the  typing  assignments  that  correspond  to  a  context  of  extraction  assumptions.  In  accor¬ 
dance  with  the  propositions-as-types  principle,  the  typing  assignment  per  that  corresponds  to 


an  extraction  assumption 


depends  only  on  the  proposition  A  and  not  on  the  proof  V.  So 


the  following  lemma  allows  us  to  translate  any  context  of  extraction  assumptions  to  a  context  of 
typing  assignments: 

Lemma  3.3  (Totality  of  type  extraction)  For  any  formula  A  there  is  a  unique  type  r  such  that 

The  proof  is  an  easy  induction  on  the  structure  of  formulas,  appealing  to  the  type  extraction 
deduction  rules  of  Figure  2.13. 

Definition  3.4  Given  a  context  of  extraction  assumptions  (  F,  A  }  where 
r  =  ijO-Xj,...,  Xffi  (j-  and  A  — 


Pi 

Ai 


Pn 

An 


Wn 


we  define 

1.  [T]  =  x'l  G  nat, . . . ,  €  nat 

2.  [A]  =p\  G  ri,...,p'„  G  r„  where  Ai 

3.  [(  r,  A  )]  =  fr],  [A],  i.e.,  the  typing  assignment  context  obtained  by  appending  [F]  and  [A]. 
With  these  definitions  we  can  generalize  Theorem  3.1  to  the  following. 

Lemma  3.5  (Type  soundness  of  extraction  in  arbitrary  contexts) 

(J.  e  and  A  then  f(F,A)]  heGr. 


//(F,A)I- 
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Since  the  extraction  judgment  depends  on  the  judgment  t  e  (extraction  from  individual  terms) 
a  type  soundness  property  for  individual  term  extraction  is  also  needed: 

Lemma  3.6  (Type  soundness  for  individual  extraction)  then  [F]  I-  e  €  nat. 

The  proof  is  trivial  since  the  only  terms  in  the  object  logic  are  natural  numbers.  Its  representation 
in  Elf  is  a  very  simple  example  of  the  partial  verification  technique  that  we  apply  to  the  proof  of 
Lemma  3.5.  Here  is  the  Elf  signature  that  represents  the  proof  of  Lemma  3.6: 

tsetm  :  extract.tm  T  M  ->  of  M  nat  ->  type, 
tsetm.zero  :  tsetm  ez.zero  tp.O. 

tsetm_succ  :  tsetm  (ex.succ  E)  (tp_s  D)  <-  tsetm  E  D. 


The  clause  tsetm-zero  corresponds  to  the  base  case  of  the  proof,  which  constructs  the  depth-one 
typing  derivation  for  the  program  expression  0.  The  clause  tsetm_succ  contains  a  subgoal  that 
represents  an  appeal  to  the  induction  hypothesis.  There  is  no  clause  translating  extraction  from 
variables  (rule  ex-ivar  of  Figure  2.15),  because  extraction  contexts  are  represented  at  the  meta-level 
as  Elf  contexts.  This  is  reflected  by  representing  the  translation  by  a  meta-level  assumption,  a 
technique  shown  in  the  presentation  to  follow. 

The  encoding  of  the  proof  of  Lemma  3.5  in  Elf  follows  the  same  basic  principles.  We  declare  a 
type  family  to  represent  the  lemma: 

tse  :  extract  (P:  |-  A)  H  ->  extract _tp  A  T  ->  of  M  T  ->  type. 


This  declaration  expresses  a  relation  between  a  program  extraction  deduction,  a  type  extraction 
deduction,  and  a  typing  assignment  deduction.  Proving  Lemma  3.5  amounts  to  giving  a  total 
function  from  the  first  two  deductions  to  the  third.  The  encoding  of  the  proof  in  Elf  is  partial  in 
the  following  sense:  we  can  code  this  function  as  an  Elf  signature,  and  the  well-typedness  of  each 
declaration  in  the  signature  guarantees  that  the  construction  carried  out  is  correct.  But  there  is  no 
internal  guarantee  that  the  signature  determines  a  total  function  (and  clearly  we  cannot  code  the 
construction  directly  as  an  Elf  function  since  it  is  not  schematic).  This  guarantee  could  probably  be 
obtained  by  applying  the  schema  checking  of  [PR92]  to  the  proofs  of  type  soundness,  and  possibly 
also  to  evaluation  soundness.  We  have  partially  schema-checked  the  type  soundness  proof  by  hand. 
Further  work  in  this  direction  is  beyond  the  scope  of  the  thesis  since  fuU  schema  checking  has  not 
been  implemented. 


We  give  some  characteristic  cases  of  the  proof.  Reference  to  Figures  2.10,  2.11  (type  assign¬ 
ment),  2.13  (type  extraction),  and  2.14  through  2.19  will  help  in  following  the  argument.  Since  the 


extraction  deduction  £  ::  (  r,A  )  h 


0  e  closely  follows  the  structure  of  the  object  proof  V  the 


cases  can  be  characterized  by  the  last  inference  of  V.  The  cases  are  of  the  following  main  kinds: 
base  cases  {V  ends  in  TI  or  one  of  the  axiom  schemas  of  arithmetic),  first-order  inductive  cases 
where  the  last  inference  does  not  bind  any  individuals  or  discharge  any  assumptions  (AI,  AE^,  AEr, 
VIl,  Vlfi,  DE,  and  lE),  and  higher-order  inductive  cases  where  the  last  inference  binds  a  parameter 
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and/or  discharges  an  assumption  (VE,  Dl,  ->!,  VI,  3E,  3l,  VE,  and  IND).  The  lemmas  needed  for 
each  type  of  case  are  introduced  as  needed.  A  simple  lemma  needed  throughout  the  proof  is: 

Lemma  3.7  (Inversion  for  type  extraction)  Given  £  ::  h  the  last  inference  rule  of  £  is 

uniquely  determined  by  the  form  of  A. 

The  proof  is  easily  seen  by  inspecting  the  rules  of  Figure  2.13. 


Base  cases 


The  base  cases  are  those  in  which  the  extraction  deduction  £  ::  (  F,  A  } 


h 


e  consists  of  the 


application  of  a  single  rule  without  premises.  For  our  simple  system  of  arithmetic,  these  are  the 
rules  for  extraction  from  a  proof  of  T,  an  equality,  or  the  negation  of  an  equality.  We  show  the 
reasoning  for  the  negative  axiom  schema  AXo. 


Ca-e  £  = 


XAXO 


(r,A)h 


AXO 


-■succ  t  =  zero 


J)neg 


By  inversion  any  type  extraction  from  -isucc  t  =  zero  has  the  form 

xt= 

xt-i 


succ  t  =  zero))*  atom 


-isucc  t  =  zero  ))*  atom  =>  void 

Then  construct  the  following  typing  deduction  of  the  form  required: 

- tp-neg 

f(  r,  A  )1  h  neg  €  atom  ^  void 


The  constructive  content  of  this  case  is  expressed  by  the  Elf  clause: 

tse_ax_zero  :  tse  ex_ax_zero 

(ext.not  (Et:  extract.tp  (eq  (succ  T)  zero)  atom)) 
(tp_neg  atom) . 


First-order  inductive  cases 

For  cases  where  the  object  proof  V  ends  in  one  of  the  rules  AI,  AEi,,  AE/i,  VU,  VIr,  DE,  or  -^E, 
no  extraction  assumptions  are  introduced  into  the  context  in  the  subdeduction(s)  of  £.  These 
cases  are  straightforward.  We  apply  the  totality  of  type  extraction  to  obtain  type  extraction 
deductions  corresponding  to  the  subdeductions.  We  can  then  apply  the  induction  hypothesis  to 
the  subdeductions.  We  show  the  case  for  DE  as  an  example. 
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Case  £  = 


£i  £2 


(F,A)h 

Vx 

adb 

(lex  (F,A)l-^2^e2 

(F,A)1- 

Vx  V2 

AdB  a 

(lapp(ei,e2) 

B 

Assume  there  is  a  type  extraction  deduction  T  :: 

Since  type  extraction  is  total  there  is  a  type  extraction  T'  A  t'.  Construct  the  type 
extraction  T"  = 

V  T 

- XtD 

A  D  =}►  T 

Applying  the  induction  hypothesis  to  £i  and  T"  yields  the  typing  deduction  2)i  ::  [(  F,  A  )]  h 

ei  €  r'  ^  r.  Applying  it  to  £2  and  T'  yields  V2  ::  [(  r,A  1-  62  €  t' .  Then  construct  the 

typing  deduction 

Vi  Z>2 

f{r,A)ll-ci€r'=J.r  [(  F,  A  )1  h  ej  €  r' 

- tp-app 

[■(  F,A  )1  l-app(ei,e2)  €  r 


□ 


The  Elf  clause  representing  this  case  is: 

tse.impliese  :  tse  (ex.impliese  E2  El)  Et  (tp.app  D2  Dl) 
<-  tse  El  (ext.implies  Et  Et’)  Dl 
<-  tse  E2  Et’  D2. 


The  two  subgoals  represent  the  two  uses  of  the  induction  hypothesis.  The  term  (ext_implies  Et 
Et  ’ )  represents  the  construction  of  the  type  extraction  T". 


Higher-order  inductive  cases 

Where  the  object  proof  V  en  ‘s  in  a  rule  involving  a  binding  construct,  some  manipulation  of  the 
context  is  required.  When  t'  t  j;..y  discharged  assumptions  and  no  bound  individuals  (VE,  Dl, 
-il).  Lemma  3.7  (inversion)  and  Definition  3.4  (context  translation)  are  sufficient  for  the  application 
of  the  induction  hypothesis.  We  show  the  case  for  Dl  as  an  example  of  this  kind  of  reasoning. 
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Case  €  = 


€• 


By  inversion  the  corresponding  type  extraction  deduction  has  the  following  form: 


Ti  Tj 

A  D  ^  T2 


By  definition  3.4,  r,(A, 


P 

A 


^p')  )i  =  e  ri. 


Applying  the  induction  hypothesis  to  S'  with  T2  yields  the  typing  deduction  V  ::  [T] ,  [A] ,  p'  € 
Ti  i-  e  e  T2.  Then  construct: 


V 


fr],  fAl,p'  e  n  I-  e  e  rz 

fr],  fA]  I-  lamp'.e  e  ri  ^  rz 


tp-lam 


This  is  the  typing  derivation  required  since  [F],  [A]  =  [{  F,  A  )]. 

□ 


The  Elf  clause  corresponding  to  this  case  is: 

tse.impliesi  :  tse  (ex.impliesi  E)  (ezt.implies  Et2  Etl)  (tp.lam  D) 
<-  ({p}  -Cp’)-  {e:  extract  p  p’}  {d}  tse  e  Etl  d 
->  tse  (E  p  p’  e)  Et2  (Dp’  d)). 


The  term  (ext_implies  Et2  Etl)  represents  the  use  of  the  inversion  principle.  Since  the  extrac¬ 
tion  S'  is  represented  as  a  term  (E)  of  functional  type,  the  appeal  to  the  induction  hypothesis  is 
represented  as  a  subgoal  of  higher-order  judgment  type.  The  type  soundness  zissumption  in  this 


subgoal  tse  e  Etl  d  represents  the  translation  of  the  assumption 


in  the  extraction  context 


to  the  typing  context  j/  €  Ti  ,  reflecting  Definition  3.4. 

When  individual  parameter  binding  is  involved,  as  in  VI  and  3E,  we  need  a  permutation  property 
for  typing  assignment  contexts: 
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Lemma  3.8  (Permutation  for  typing  assignment  contexts)  e  Ti,r2,X2  €  T-2,r3  h  e  e  t 

then  Fi.xa  €  r2,r2,xi  €  ri,r3  I-  e  6  r. 

The  lemma  can  be  proved  by  an  easy  induction  on  the  structure  of  typing  derivations,  keeping  in 
mind  the  assumption  that  no  variable  occurs  more  than  once  in  a  context. 

Here  is  the  reasoning  for  type  soundness  for  Vl.  It  has  nearly  the  same  structure  as  the  Dl  case. 


Case  €  = 


£• 

((r,irx'),A)i- 


(r,A)i- 


XVI 


(1  lam  x' .  e 


By  inversion  the  corresponding  type  extraction  deduction  has  the  following  form: 


V 


Vx .  nat  =>•  r 


xtv 


By  definition  3.4,  r(  (r,x(|.‘  x'),  A  )]  =  rr‘l,x'  €  nat,  [A]. 

Applying  the  induction  hypothesis  to  €'  with  T  yields  the  typing  deduction  V  ::  [r],x'  € 
nat,  [A]  h  e  €  r.  We  apply  the  permutation  lemma  to  obtain  a  typing  deduction  V  :: 
[r] ,  [A] ,  x'  G  nat  t-  e  e  r. 


Then  construct: 


V 

[r],  [Al,x'  G  nat  h  e  G  r 

- tp-lam 

[r] ,  [A]  h  lam  x' .  e  G  nat  =>  r 


□ 

The  Elf  clause  implementing  this  case  is: 

tse_foralli  :  tse  (ex.foralli  E)  (ext.forall  Et)  (tp.lam  D) 

<-  ({x}  {x’}  {e : extract.tm  x  x’}  {d} 

tsetm  e  d  ->  tse  (E  x  x’  e)  (Et  x)  (D  x’  d)). 


Again  we  use  a  subgoal  of  higher-order  judgment  type  to  represent  the  use  of  the  induction  hypoth¬ 
esis.  In  this  case  the  context  translation  is  represented  by  the  assumption  tsetm  e  d,  since  the 
context  is  extended  in  its  individual  variable  domain  rather  than  its  proof  variable  domain.  The 
use  of  the  permutation  lemma  is  not  explicit,  because  contexts  are  represented  as  LF  contexts,  for 
which  permutation  holds. 
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The  rules  31,  VE,  and  IND  involve  substitution  in  propositions.  These  cases  use  the  property 
that  substitution  of  individuals  has  no  effect  on  type  extractions: 

Lemma  3.9  Substitution  lemma  for  type  extraction:  //I-  t  then  I-  r. 

The  proof  is  quite  simple,  but  requires  a  definition  of  substitution  for  individual  variables  in  type 
extraction  deductions.  For  any  T  ::  .4  r,  the  substitution  of  a  term  t  for  an  individual  variable 
X  in  T  is  constructed  by  substituting  t  for  x  in  A,  and  recursively  substituting  t  for  x  in  any 
subdeductions  of  T.  It  is  easy  to  see  that  this  results  in  a  valid  type  extraction  T' ::  [t/x]i411‘  r. 

In  addition  the  extraction  rules  for  3l  and  VE  depend  on  extractions  from  individual  terms  of 
the  logic,  so  these  cases  use  Lemma  3.6  (type  soundness  for  extraction  from  individuals). 

We  give  the  reasoning  for  the  rule  of  existential  introduction: 

Case  £  = 


By  inversion,  the  corresponding  type  extraction  deduction  has  the  form 

Ti 

t' 

- Xt3 

3x  .  A  nat  x  r' 

Applying  Lemma  3.9  (substitution  in  type  extractions)  to  Ti,  we  obtain  a  type  extraction 
72  ::  [</x]A(l.‘ r'.  Lemma  3.6  applied  to  £%  gives  the  typing  assignment  Vi  ::  [(  r,A  )]  I- 
Ci  €  nat.  Then  the  induction  hypothesis  applied  to  £2  with  T2  yields  the  typing  assignment 
X>2  "  R  r,  A  )]  I-  €2  €  r',  and  thus 


Vi 


V2 


[(r,A)l  l-ei  €nat  R  F,  A  )]  h  €2  G  r' 

- tp-pr 

R  r,A  )1  h  (  ei,e2  )  €  nat  x  t' 


The  Elf  clause  for  this  case  is: 

tse.existsi  :  tse  (ex_existsi  E2  (El: extract _tm  T  M)) 
(ext. exists  Et)  (tp.pair  D2  Dl) 

<-  tsetm  El  Dl 
<-  tse  E2  (Et  T)  D2. 
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The  term  (Et  T)  represents  the  use  of  the  substitution  lemma.  This  representation  is  justified 
by  a  general  property  (called  compositionality  in  (HHP93])  of  our  encodings.  Compositionality 
guarantees  that  representations  are  faithful  with  respect  to  substitution.  In  particular,  [T/x]E 
represents  [t/x]e  if  T  represents  t  and  E  represents  e  (where  the  parameter  x  is  identified  with  the 
variable  x).  Recall  that  the  higher-order  abstract  syntax  encoding  of  3  represents  3x  .  A  as  a  term 
oi  the  form  (exists  A)  where  A  has  functional  type.  Thus  the  Elf  representation  of  the  type 
extraction  rule  xt3  contains  a  premise  of  (dependent)  functional  type  as  well: 

ext.exists  :  extract.tp  (exists  A)  (*  nat  Tp) 

<-  {x:i>  extract.tp  (A  x)  Tp. 


So  the  representation  of  the  type  extraction  deduction  T\  is  not  Et  but  (Et  x)  for  some  parameter 
X,  and  we  obtain  the  substitution  [T/x](Et  x)  by  /3-reduction  of  the  term  (Et  T). 


3.2  Type  soundness  for  extraction/simplification 

A  type  soundness  theorem  for  the  extraction/simplification  judgment  j),  is  more  valuable,  cis  the 
property  is  no  longer  so  obvious.  We  present  the  proof  as  a  modification  of  the  proof  of  the  previous 
section. 

Theorem  3.10  (Type  soundness  of  extraction/simplification)  If  h 
e  G  T, 

Again  we  generalize  the  theorem  to  arbitrary  contexts,  so  a  translation  of  extraction  assumption 
contexts  to  typing  assignment  contexts  is  needed.  The  required  definition  is  the  obvious  modifi¬ 
cation  of  Definition  3.4.  For  the  translation  to  be  well-defined,  we  need  the  analog  of  Lemma  3.3, 
totality  of  type  extraction. 

Lemma  3.11  (Totality  of  type  extraction/simplification)  For  any  formula  A  there  is  a  unique  type 
T  such  that  H  r. 

The  proof  is  an  easy  induction  on  the  structure  of  formulas,  appealing  to  the  type  extraction 
deduction  rules  of  Figure  2.23,  together  with  the  following  (easily  seen  by  inspection  of  Figures  2.20 
through  2.22): 

Lemma  3.12  The  judgment  Inf  is  the  complement  of  the  judgment  Uninf,  and  for  any  formula 
A,  i/HarropA  is  deducible  then  Uninf  A  is  deducible. 


(li  e  and  h  A  r  then  h 


Definition  3.13  Given  a  context  of  extraction  assumptions  (  r,A  )  where 


r  =  xi  )J.‘  x'l, . . . ,  Xm  x'^  and  A  = 
we  define 


Pi 

Ai 


Pn 

A„ 


i.  fr]  =  x'l  G  nat, . . .  G  nat 
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II.  fAl  =  p'l  €  ri, . . .  ,p;  6  r„  where  Ai  .(11  n, . . . ,  An  Tn- 

Hi.  [(  r,  A  )]  =  [r],  fA],  i.e.,  the  typing  assignment  context  obtained  by  appending  [F]  and  [A]. 


Using  these  definitions  we  generalize  the  type  soundness  theorem  as  before: 
Lemma  3.14  (Type  soundness  of  extraction/simplification  in  arbitrary  contexts) 
If  {  r,A  )  I-  ^  ii-sC  and  I-  AO-Jr  then  f{  r,A  )]  h  e  €  r. 


Extraction/simplification  depends  on  the  same  individual  term  extraction  judgment  D’  that 
naive  extraction  does,  thus  Lemma  3.6  (type  soundness  for  term  extraction)  is  used  in  the  new 
proof. 

We  appeal  to  an  inversion  principle  for  type  extraction/simplification  throughout  the  proof,  a 
modification  of  Lemma  3.7. 

Lemma  3.15  (Inversion  for  type  extraction/simplification)  Given  €  ::  A]\,[t,  the  last  inference 
rule  of  £  is  uniquely  determined  by  the  form  of  A. 

This  is  proved  easily  by  inspection  of  the  inference  system  of  Figure  2.23,  keeping  in  mind  Lemma  3.12. 

Again  we  present  a  few  characteristic  cases  of  the  induction  on  the  structure  of  the  given  extrac¬ 
tion  deduction  £.  Reference  to  Figures  2.10, 2.11,  2.20  through  2.27,  and  2.30  will  help  in  following 
the  presentation. 

When  the  extraction  deduction  ends  in  a  rule  that  does  no  simplification  (aU  subformulas  are 
informative)  the  proof  for  naive  extraction  carries  over  directly.  Thus  we  do  not  show  the  reasoning 
for  deductions  ending  in  xsaI,  xsaEi,,  xsaEr,  xsdI,  xsdE,  xvi,  xvE,  xs3l,  xs3E,  or  xsiND  of  Figures  2.25 
through  2.29.  Of  the  extractions  that  perform  simplifications,  we  again  have  base  cases,  first-order 
inductive  cases,  and  higher-order  inductive  cases. 


Base  cases 

The  base  cases  concern  extraction  from  uninformative  proofs,  where  the  end  formula  is  a  Har- 
rop  formula,  a  negation,  or  ±.  The  first  two  of  these  are  trivial,  constructing  depth-one  typing 
derivations  corresponding  to  the  depth-one  extraction  derivations. 

Although  the  reasoning  is  easy  it  is  worth  examining  the  case  for  extraction  from  proofs  of  J. 
since  it  has  no  analog  in  the  proof  for  naive  extraction. 


Case  £  = 


(r,A)i- 


V 

X 


1),  app(neg,()) 


xsX 


Assuming  the  type  extraction  T  ::  ID-jT,  the  inversion  principle  gives  r  =  void.  Then 
construct 

- tp-neg  - tp-unit 

(’(  r,  A  )]  I-  neg  6  unit  void  [(  F,  A  )]  H  ()  6  unit 

tp-app 


(■(  F,A  )]  h  app(neg,())  e  void 
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□ 


The  Elf  clause  for  this  case: 

tse.f  :  tses  exs.f  exts.false  (tp.app  tp.unity  (tp.neg  unit)). 


First-order  inductive  cases 

When  the  object  proof  ends  in  one  of  the  inference  rules  AI,  AE^,,  AEr,  VI/,,  Vln,  DE,  or  -lE,  and 
one  of  the  subproofs  is  uninformative,  the  extraction  rule  performs  simplification.  As  in  the  proof 
for  naive  extraction,  these  cases  are  straightforward  because  no  assumptions  are  introduced  into 
the  context.  Verifying  them  simply  requires  checking  that  the  type  extraction/simplification  rules 
and  the  program  extraction/simplification  rules  match  up  correctly,  dropping  the  appropriate  parts 
of  the  types  and  program  expressions.  As  an  example  we  show  the  case  for  DE. 


Case  C  = 


xsder 


Assume  there  is  a  type  extraction  deduction  T  ::  r. 

Construct  the  type  extraction  T'  = 


U  I 

UninfA  Inf  5 


T 


- XStDR 


Applying  the  induction  hypothesis  to  €'  and  T'  yields  the  typing  deduction  "D  ::  [(  F,  A  )]  h 
e  G  r  as  required. 

□ 


The  Elf  clause  that  implements  this  case  follows. 

tse.impliesel  :  tses  (exs.implel  E’  Ib  Ua)  T  D 

<-  tses  E’  (exts.impr  T  Ib  Ua)  D. 
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Higher-order  inductive  cases 

Of  the  higher-order  cases,  only  those  for  object  proofs  ending  in  Dl,  3l,  and  3E  involve  simplifica¬ 
tions  other  than  extraction  of  ().  If  i4  is  uninformative,  to  extract  a  program  from  a  proof  o{3x  .A 
by  3l  we  extract  just  an  expression  e  representing  the  witness  t  for  which  [t/xjA  holds,  instead  of 
a  pair.  As  a  result  the  proof  for  this  case  is  simpler  than  its  counterpart  for  the  case  where  A  is 
informative,  since  there  is  no  need  to  reason  about  the  type  extracted  from  [t/x]A.  In  fact  although 
the  representation  of  the  object  proof  is  higher-order,  the  construction  for  this  case  is  represented 
using  only  first-order  subgoals. 


Case  S  = 


U 

Uninf  A 


£' 


(r,A)H 


XS3IL 


The  type  extraction  from  3x  .  A  must  have  the  form: 


U 

Uninf  A 
Bx  .A  nat 


XSt3L 


By  Lemma  3.6  (type  soundness  for  term  extraction)  there  is  a  typing  derivation  V  ::  [(  F,  A  )]  h 
e  e  nat  as  required. 

□ 


The  Elf  clause  that  expresses  this  case  is: 

tse.existsil  :  tses  (exs.existsil  (Etm:extract_tm  T  M)  Ua) 
(exts.exl  Ua)  D 
<-  tsetm  Etm  D. 


Next  we  consider  cases  (xsdIR  or  xs3EL)  where  the  object  proof  discharges  an  uninformative 
assumption  and  as  a  result  the  extracted  program  is  simplified.  (Uninformative  assumptions  can 
also  be  discharged  by  VE  and  IND,  but  they  do  not  affect  the  extraction:  in  the  case  of  the  induction 
rule  IND,  if  the  discharged  assumption  is  uninformative,  so  is  the  end-formula  of  the  proof,  so  the 
extraction  rules  for  Harrop  and  negative  formulas  cover  this  case.  In  the  case  of  VE  where  the 
major  premise  is  A  V  J3  with  both  A  and  B  uninformative,  e.xtraction  nevertheless  retains  the 
information  of  which  holds,  A  or  B.) 

When  extracting  from  proofs  ending  in  Dl  or  3E  the  uninformative  assumptions  do  not  lead  to 
the  introduction  of  assumptions  in  the  extraction  deduction  (see  the  discussion  in  Section  2.3.2  and 
the  rules  in  Figure  2.27  and  Figure  2.28).  As  a  result  the  reasoning  for  Dl  does  not  involve  any 
extension  of  the  context: 
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Case  €  = 


£• 


XSDIR 


The  corresponding  type  extraction  must  have  the  form: 


U  IT 

Uninf>l  Inf  5 

- XStDR 

ADBi^iT 

By  the  induction  hypothesis  applied  to  I'  and  T  there  is  a  typing  derivation  V  ::  e  £  t  ns 
required. 

□ 


The  following  Elf  rule  formalizes  this  case. 

tse.impliesil  :  tses  (exs.implil  E  Ib  Ua)  (exts.impr  Etb  Ib  Ua)  D 
<-  ({p}  tses  (E  p)  Etb  D) . 


Although  the  subgoal  introduces  the  parameter  p  it  does  not  introduce  any  assumptions  on  p. 
This  reflects  the  fact  that  p  stands  for  an  uninformative  proof  whose  structure  cannot  affect  the 
extraction  (E  p)  (Lemma  2.1  of  Section  2.3.2). 

Extraction  for  3E  extends  the  context,  but  only  in  its  individual  variable  domain. 


Case  £  = 


U 

Uninf  A 


1 

€2 

P 

(r,A)i- 

V 

3x.A 

((r,x4'x'),A}h 

A 

Q 

£] 

(r,A)i- 


V 

3x.A 

C 


)).,  app((lamx'.P2),ei) 


XS3EL 


Assume  C 
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Construct  the  type  extraction  derivation  7i  = 


U 

Uninfy4 

-  XSt3L 

3a: .  nat 

By  the  induction  hypothesis  applied  to^^i  and  Tj,  there  is  a  typing  deduction  Pi  r,A  )]  h 
ei  €  nat. 

By  the  induction  hypothesis  applied  to  ^^2  and  T^,  there  is  a  deduction  P2  ::  [{  a-'),  A  )]  h 

C2  €  T,  By  definition  [{  (r,a;l|.' a:'),  A  )]  =  ^  nat,  [A].  By  permutation  for  typing 

assignment  contexts,  there  is  a  deduction  P2  ;;  [F],  fA],a:'  E  nat  €  t.  Then  construct 

P' 

p  r,  A  )],x' 6  nat  h  62  G  r 

- tp-lam 

[(  r,  A  )]  (-  lam x'. 62  G  nat  =>  r  ['(  r,A  )]  f-  d  G  nat 

- ^ - tp-app 

f(  r,  A  )]  H  app(lamx  .62,61)  €  r 


This  case  is  formalized  by  the  following  Elf  clause. 

tse.existsel  :  tses  (exs.existsel  Ee  Ec  U)  Et 

(tp_app  D1  (tp_lam  D2)) 

<-  tses  Ee  (exts.exl  U)  D1 
<-  ({x}  {x’}  -Cetm; extract.tm  x  x’} 

{d}  tsetm  etm  d  -> 

•fp}  tses  (Ec  X  x’  etm  p)  Et  (D2  x’  d)). 


As  in  the  previous  case  the  last  subgoal  introduces  the  uninfor .native  proof  parameter  p  without 
introducing  assumptions  on  p. 


3.3  Evaluation  Soundness 

The  proof  of  evaluation  soundness  for  naive  extraction  is  an  induction  on  the  structure  of  the 
evaluation  deduction  V  ::  6  <— *■  u  (see  Figure  2.8  for  the  evaluation  inference  system).  Each  case 
of  the  induction  constructs  an  object  proof;  since  evaluation  is  closely  related  to  proof  reduction, 
this  gives  us  a  set  of  executable  reductions  for  object  proofs.  Note  that  we  are  not  proving  a 
normalization  theorem  for  the  object  logic,  and  because  the  semantics  does  not  evaluate  under 
functional  abstractions,  the  soundness  proof  does  not  give  even  weak  normal  forms  in  the  sense  of 
Prawitz  [Pra71]. 

Again  we  generalize  to  arbitrary  contexts  of  extraction  and  prove  the  following  lemma. 
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Lemma  3.16  //h  e  v  and  (  F,  A  )  I-  ^  J|e  then  there  is  a  proof  V  such  that  (  F,  A  )  I- 

The  following  judgment  represents  the  lemma  in  Elf: 

tr_ev  :  eval  M  V  ->  extract  (P;|-  A)  M  ->  extract  (P’:|-  A)  V  ->  type. 

As  for  type  soundness,  we  need  a  related  lemma  for  extraction  from  individual  terms.  It  is  partic¬ 
ularly  simple  because  of  the  limited  nature  of  our  theory;  in  fact  any  expression  extracted  from  an 
individual  evaluates  to  itself. 

Lemma  3.17  If  T  \-  t  e  and  e  v  then  F  I-  <  u 

The  Elf  signature  representing  this  lemma  and  its  proof  follows. 

tr_ev_tin  :  eval  MM’  ->  extract_tm  T  M  ->  extract_tm  T  M*  ->  type. 
tr_ev_tm_z  :  tr_ev_tm  ev_0  ex.zero  ex_zero. 

tr_ev_tm_s  :  tr_ev_tm  (ev_s  Ev)  (ex.succ  E)  (ex.succ  E’)  <-  tr.ev.tm  Ev  E  E’ . 

We  do  not  have  as  clean  an  inversion  principle  as  for  type  soundness:  the  form  of  an  extracted 
program  limits  but  does  not  uniquely  determine  the  last  inference  of  the  extraction.  Inspection  of 
the  extraction  rules  of  Figures  2.16  -  2.19  gives  the  following  correspondences. 

Lemma  3.18  (Inversion  for  program  extraction) 

'P 

7/5  ::  (  F,  A  )  h  .  -ll-e,  then  the  form  of  e  and  the  form  of  A  determine  the  last  inference  of  £  as 
A. 

follows. 

Lea  variable  :  ex-pvar 

2.  If  e  =  0  or  e  =  s(e)'  then  e  cannot  be  extracted  from  an  object  proof. 

3.  e  =  (  ei,e2  )  ;  Inspection  of  the  extraction  rules  gives  xa\  or  x3l.  But  since  the  object  proofs  in 
question  end  in  introduction  rules,  the  outermost  connective  of  A  is  enough  to  disambiguate. 

4.  e  =  fst(e')  .-  xaEl 

5.  e  =  snd(e')  ;  xaEr 

6.  e  =  spread(ei;  x,y.e2)  :  x3E 

7.  e  =  inl(e’)  ;  xvit 

8.  e  =  inr(e')  ;  xvi^ 

9.  e  =  decide(ei;  x.e2',  x.e^)  :  xvE 


10.  €  =  lamx.e'  ;  The  extraction  must  end  in  xdI,  xvi,  orx->I.  But  again  these  are  all  introduc¬ 
tion  rules,  and  the  outermost  connective  of  A  uniquely  determines  the  last  inference. 


11.  e  =  natJnd(ei;  x^y.e^)  :  xind 

12.  e  —  app(ei,e2)  •  xdE,  xve,  orx-.E 

13.  e  =  0  :  xT 

14.  e  =  any(e)  :  xl 

15.  e  =  neg  :  xAXo 

16.  e  =  axiom  :  x=R,  x=Y,  x=T,  x=u,  or  xaxs 


We  also  need  a  substitution  lemma  for  program  extractions.  A  fully  detailed  proof  requires 
definitions  of  substitution  for  program  expressions,  logical  formulas,  natural  deduction  proofs,  and 
extraction  contexts.  We  omit  the  details  as  there  is  nothing  unusual  about  them,  except  for 
contexts.  Here  we  only  define  substitution  for  an  individual  variable  in  a  context: 


Definition  3.19  (Substitution  in  contexts) 


[t/x]A 


lip' 


is  defined  only  if  A  and  B  are 

identical. 

Lemma  3.20  (Substitution  in  program  extractions) 


Note  also  that  substitution  of  a  proof 


for  a  proof  variable 


a.  if{  r. 


De' 


Corollary:  If  x  is  not  free  in  A, 


and  {  (r,a:r  a:'),(A, 


(l-c  and  r  h  and  (  F,  A  )  h  [tlx] 


then  (  r,A  )  h  [tlx][Qlq^^l^[etlx'][eQlq']t 
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The  proof  is  again  a  structural  induction  on  extraction  deductions,  and  depends  on  a  similar 
lemma  guaranteeing  that  substitution  of  individual  terms  and  proofs  in  natural  deductions  preserves 
validity. 

The  proof  of  the  main  lemma  3.16  is  a  straightforward  induction  on  the  structure  of  the  evalu¬ 
ation  deduction;  we  present  only  a  sample  of  typical  cases  and  their  representation  in  Elf. 


Base  cases 

In  the  case  that  e  e  (ev-lam,  ev-pr,  ev-unit,  ev-ax,  and  ev-neg)  the  conclusion  is  immediate.  Each 
case  is  represented  in  Elf  by  a  clause  without  subgoals: 

tr_ev_lam  :  tr_ev  ev.lam  E  E. 
tr_ev_pr  :  tr_ev  ev_pr  E  E. 
tr_ev_unity  :  tr_ev  ev_unity  E  E. 
tr_ev_ax  :  tr.ev  ev_ax  E  E. 
tr_ev_neg  :  tr_ev  ev_neg  E  E. 


Congruence  cases 

Where  evaluation  merely  descends  through  anon-binding  constructor  (ev-pair,  ev-ini,  and  ev-inr)  the 
conclusion  follows  easily  by  applying  the  induction  hypothesis  or  Lemma  3.17  (evaluation  soundness 
for  individuals)  to  the  subdeduction(s)  of  the  evaluation.  The  cases  ev-inI  and  ev-inr  are  trivial.  We 
show  the  case  where  the  evaluation  ends  in  ev-pair  in  detail. 

Assume  V  = 

Vl  V2 

ei  ^  Vl  €2^  V2 

- ev-pair 

(  ei,e2  )  <—  (  vi,U2  ) 

Then  there  are  two  subcases:  the  corresponding  extraction  S  ends  in  xaI  or  x3l  (Lemma  3.18). 


Case  £  = 


£i  £2 


By  the  induction  hypothesis  applied  to  Vi  and  £i  there  is  an  object  proof  V'l  such  that 
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V[ 

A 


Similarly  we  have  €'2  :: 


A 


11 W2.  Then  construct 


F' 

£-2 


□ 

Case  €  = 


By  Lemma  3.17  (evaluation  soundness  for  individuals)  we  have  ::  F  t-  By  the 

induction  hypothesis  for  V2  and  £2  there  is  an  extraction  ::  (  r,A  )  H 
construct 


V 

[t/x]A 


i^V2.  Then 


^1' 


£!, 


XAl 


The  constructive  content  of  this  case  is  represented  by  the  following  pair  of  Elf  clauses. 

tr_ev_pr_and  :  tr_ev  (ev.pair  Evr  Evl)  (ex.andi  Er  El)  (ex.andi  Er’  El’) 
<-  tr_ev  Evr  Er  Er’ 

<-  tr_ev  Evl  El  El’. 


tr_ev_pr_ex  :  tr_ev  (ev_pair  Evr  Evl)  (ex.existsi  Er  El)  (ex.existsi  Er’  El’) 
<-  tr_ev_tm  Evl  El  El’ 

<-  tr.ev  Evr  Er  Er’. 
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The  other  congruence  cases  are  similarly  encoded  in  Elf. 

tr_ev_inl  :  tr.ev  (ev.inl  Ev)  (ei.oril  E)  (ex.oril  E’) 
<-  tr.ev  Ev  E  E’ . 

tr.ev.inr  :  tr.ev  (ev.inr  Ev)  (ex.orir  E)  (ex.orir  E’) 
<-  tr.ev  Ev  E  E’. 


The  evaluation  rule  for  successor  (ev-s)  is  also  a  congruence,  but  the  conclusion  follows  trivially 
since  there  is  no  rule  that  extracts  an  expression  (s(e))  from  a  proof. 


Reduction  cases 

Proof  reductions  arise  from  eliminations  (ev-fst,  ev-snd,  ev-spread,  ev-decide-l,  ev-decide-r,  ev-app-lam, 
ev-pr-z,  and  ev-pr-s). 

The  cases  for  evaluation  of  fst(e)  and  snd(e)  are  dual;  we  show  the  reasoning  for  fst(e). 


Case  V  = 

Vx 

€  <-♦  <  Vl,V2  ) 
fst(e)  <-►  vi 

By  inversion  an  extraction  £  of  fst(e)  has  the  form 

(r,A)i- 


ev-fst 


V 

A  A  B 


i^e 


(r,A)l- 


•XAEi 


^fst(e) 


By  the  induction  hypothesis  on  Vi  and  £i  we  have  an  extraction  £'  from  a  proof  of  A  A  B 
which  by  inversion  has  the  following  form: 


ft  ft 

tj  C.2 


□ 
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This  case  and  its  dual  are  represented  in  Elf  by  the  clauses; 

tr_ev_fst  :  tr_ev  (ev.fst  Ev)  (ex.andel  E)  El 
<-  tr.ev  Ev  E  (ex.andi  Er  El) . 
tr_ev_snd  :  tr_ev  (ev.sud  Ev)  (ex.emder  E)  Er 
<-  tr_ev  Ev  E  (ex.andi  Er  El) . 


Case  V  = 


Vi  V2 

ei )  [vilx][v2ly]e2^  v 

- ev-spread 

spread(ei',  x,y.e2)'—^  v 

By  inversion  the  extraction  €  has  the  form 


S2 


By  the  induction  hypothesis  on  Vi  and  £\  we  have  an  extraction  of  (  Ui ,  t;2  )  from  a  proof  of 
.  y4.  By  inversion  the  extraction  has  the  following  form. 


X3I 


Then  Lemma  3.20  (substitution),  applied  to  €2-,  £\,  and  £'2  allows  us  to  substitute  t  for  r',  ui 
for  I,  V  for  y',  and  V2  for  y  in  £2-  (Since  x'  is  not  free  in  A  we  can  apply  the  corollary.)  We 
obtain  the  extraction 


y' 

A 

<2 

C 


r::(r,A)l-[t/x'][W] 


^yilx][v2ly\e2 
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Since  x'  is  not  free  in  C,  [tlx'][V'l]/\ 


hypothesis  to  V2  and  €'  we  have  a  Q'  such  that  (  F,  A  )  I- 

□ 


is  a  proof  of  C.  Then  applying  the  induction 

as  required. 


Q‘ 

C 


The  Elf  representation  of  this  case  is  an  example  of  the  use  of  term  reconstruction  to  manage  the 
details  of  the  proof: 

tr_ov_spread  :  tr.ev  (ev.spread  Ev_r  Ev_p)  (ex.existse  E_gx  E_min)  E’ 

<-  tr_GV  Ev_p  E_ex  (ex.existsi  E  Etm) 

<-  tr_Gv  Ev_r  (E_min  _  _  Etm  _  _  E)  E* . 


The  terms  that  represent  t,  ui,  V ,  and  V2  of  the  informal  proof  need  not  be  supplied  (they  corre¬ 
spond  to  the  underscores  in  the  input)  since  they  are  found  during  term  and  type  reconstruction 
for  the  clause. 

The  two  evaluation  rules  for  decide  are  dual  to  one  another.  We  show  the  case  for  left  injection. 


Case  V  = 

Vi  V2 

ei  inl(wi)  [v\lx]e2  v 

- - - ev-decide-l 

decide(ei;  x  .e2\  x  v 

By  inversion  any  extraction  S  of  decide(ei;  x  .€2',  x  .63)  has  the  form 


The  induction  hypothesis  for  Vi  and  together  with  inversion,  gives  E[  = 


(r,A)i- 


O-Ul 


(r,A)i- 


■xvli 
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We  use  the  Substitution  Lemma  applied  to  £2  and  £'{  to  obtain 


^^:(r,A)l-(P/p] 


P 

A 

V2 

C 


^[ni/x]e2 


Then  the  induction  hypothesis  applied  to  Vj  and  €2  yields  an  extraction  of  v  from  a  proof  of 
C  as  required. 

□ 

This  case  and  its  dual  are  represented  in  Elf  as  follows.  Again  term  reconstruction  relieves  us  of 
the  need  to  supply  all  the  terms  involved  in  the  use  of  the  Substitution  Lemma. 

tr_ev_decl  :  tr_ev  (ev.dec.l  Ev  Ev_l)  (ex_ore  Er  El  E)  E*' 

<-  tr_ev  Ev_l  E  (ax.oril  E’) 

<-  tr.ev  Ev  (El  _  _  E’)  E”. 

tr_ev_decr  :  tr.ev  (ev.dec.r  Ev  Ev.r)  (ex.ore  Er  El  E)  E” 

<-  tr.ev  Ev.r  E  (ex.orir  E*) 

<-  tr.ev  Ev  (Er  .  .  E‘)  E‘’. 


Case  V  = 

Vi  V2  V3 

ei  <-+  lamr  .e  €2’-^  V2  [^2/*]^  v 

- ev-app-lam 

app(ei,e2)  ^  v 

By  inversion  there  are  three  possible  forms  for  the  corresponding  extraction  £:  the  object 
proof  can  end  in  DE,  ->£,  or  VE.  The  proofs  for  these  cases  present  no  new  features;  in  each 
subcase  we  employ  inversion  and  substitution  to  obtain  an  extraction  deduction  to  which  the 
induction  hypothesis  applies,  and  the  resulting  object  proof  is  the  obvious  reduction  of  the 
original  one. 

□ 

The  Elf  code  that  implements  the  three  subcases  is: 

tr_ev_lam_all  :  tr.ev  (ev.app.lam  Ev.r  Ev.arg  Ev.lam)  (ex.foralle  Etm  E)  E*’ 

<-  tr.ev  Ev.lam  E  (ex.foralli  E') 

<-  tr.ev.tm  Ev.arg  Etm  Etm’ 

<-  tr.ev  Ev.r  (E’  .  .  Etm’)  E”  . 

tr.ev.lam.imp  :  tr.ev  (ev.app.lam  Ev.r  Ev.€u:g  Ev.lam)  (ex.impliese  E.min  E.maj)  E’ 
<-  tr.ev  Ev.lam  E.maj  (ex.impliesi  E) 

<-  tr.ev  Ev.arg  E.min.  E.min’ 

<-  tr.ev  Ev.r  (E  .  .  E.min’)  E’. 


tr_ev.lam.not  :  tr.ev  (ev.app.lam  Ev.r  Ev.arg  Ev.lam)  (ex.note  E.pos  E.neg)  E’ 
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<-  tr_ev  Ev.lam  E.neg  (ex.noti  E) 
<-  tr.ev  Ev.arg  E.pos  E_pos* 

<-  tr.av  Ev_r  (E  _  _  E.pos’)  E’ . 


Case  V  = 


Vi  V2  V3  V4 

ei natJnd(e,;  z.y.e,)  62 s(t;2)  app((natJnd(e,;  z.y  .e,)),  V2) ^3  [v2/z][t;3/y]e, 

app(ci,e2)  t) 


I 

—  ev-pr-s 


By  inversion  there  are  three  possible  forms  for  the  corresponding  extraction  E\  the  object 
proof  V  can  end  in  DE,  ->E,  or  VE. 

If  V  ends  in  DE,  then  e\  is  extracted  from  a  proof  of  an  implication  A  D  B.  Since  Ci  » 
nat  Jnd(ez;  x,  y .  e,),  by  induction  there  is  another  proof  of  A  D  B  from  which  we  can  extract 
natJnd(e2;  By  inversion  this  extraction  must  end  in  xiND;  but  this  is  impossible. 

The  same  reasoning  applies  to  -lE;  therefore  the  only  case  to  consider  is  VE.  Here  we  see  that 
the  inversion  principle  is  too  weak,  and  we  must  appeal  to  the  induction  hypothesis  to  prove 
the  totality  of  the  translation  function  we  are  constructing.  This  is  a  weakness  in  the  proof 
that  could  be  avoided  if  we  used  a  different  encoding  of  induction  in  the  object  logic. 


£  = 


XVE 


By  the  induction  hypothesis  applied  to  Vi  and  £i  we  have  an  extraction  which  by  inversion 
has  the  form; 


Ss 
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By  lemma  3.17  applied  to  V2  and  €2  we  have  an  extraction  of  s(r2).  This  must  have  the  form 

e!2 

ri-t'r  V2 

- ^ - xtm-s 

r  f-  SUCC  s(v2) 

where  t  ~  succ  t' . 

From  E[  and  £'2  we  construct  the  extraction 
^3  = 

-  ^2 

{  r,  A  }  h  ^  .().  nat  Jnd(ej;  x,y.e^)  F  h  .il'  r2 

- XVE 

V 

{r,A)l-  .A  ^app(nat_ind(ej;  x,y.e^),V2) 

[t'/x']A 

Then  we  can  apply  the  induction  hypothesis  to  V3  and  £3  to  obtain 

[i'/x']A 

By  the  substitution  lemma  applied  to  £a  with  £2  and  £3  we  have 

j/ 

5'  ::  (  r,  A  >  f-  [<72^'][^7y']  ^[V2lx][v3ly\es 

[succ  x' /x']  A 

Since  succ  t'  =  t  the  conclusion  of  the  object  proof  is  [tlx]A.  Then  the  induction  hypothesis 
applied  to  V4  and  gives  an  extraction  of  v  from  a  proof  of  \tlx]A  as  required. 

□ 

The  following  Elf  code  represents  the  constructive  content  of  this  case: 
tr_ev_prs  : 

tr_ev  (ev_pr_s  Ev_s  Ev  Ev_p)  (ex.foralle  (ex.succ  Etm)  E)  E’ 

<-  tr_ev  Ev_p  E  (ex_ind  Es  Ez) 

<-  tr_ev_tin  Ev  (ex_succ  Etm)  (ex_succ  Etm*) 

<-  tr_ev  Ev_s  (Es  _  _  Etm’  _  _  (ex.foralle  Etm’  (ex_ind  Es  Ez)))  E’. 
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3.4  Discussion 


We  have  shown  a  fragment  of  the  metatheory  of  the  implementation.  Type  soundness  is  illustrated 
by  the  following  diagram.  The  colon  is  LF  typing;  pf  $  is  the  type  of  object  proofs  with 
conclusion  $.  The  dotted  arrow  corresponds  to  the  typing  derivation  constructed  by  the  soundness 
proof. 

(Proof)  V - = - ►(LF  type)  pf$ 


(Program)  M  —  ~  —  -►  (Type)  r 


The  following  diagram  illustrates  evaluation  soundness  in  the  same  way.  The  dotted  arrow  la- 
beUed  “reduce”  corresponds  to  the  relation  between  the  given  proof  V  and  the  proof  V'  constructed 
by  the  soundness  proof. 


(LF  type)  pf$ 


(Proof)  p  —  —  —  —  - 
reduce 


-(Proof)  V 


(Program)  M 


I 

(Program)  V 


An  immediate  consequence  of  type  and  evaluation  soundness  together  is  subject  reduction  for 
the  set  of  programming  language  expressions  that  can  be  extracted  from  proofs. 

Other  correctness  theorems  could  be  encoded  in  the  same  way.  (For  an  implementation  in 
the  same  style  of  the  metatheory  of  an  encoding  of  Mini-ML  similar  to  our  programming  language 
encoding,  see  [PR92].)  Type  and  evaluat.on  soundness  would  then  allow  us  to  carry  the  metatheory 
over  from  the  domain  of  programs  to  the  domain  of  proofs;  for  instance,  we  could  get  a  very  weak 
normal  form  for  natural  deduction  proofs  from  a  proof  that  evaluation  of  an  extracted  program 
produces  a  “value”  (for  some  appropriate  definition  of  value). 


Chapter  4 

Proof  transformation 


The  proof  transformations  considered  in  this  thesis  are  for  the  most  part  syntactic  transformations 
expressible  by  means  of  higher-order  patterns  in  the  spirit  of  Huet  and  Lang  [IIL78].  The  next 
chapter  explores  the  application  of  these  transformations  in  program  development  without  giving 
details  of  their  implementation.  This  chapter  gives  a  detailed  account  of  one  proof  transformation 
and  its  implementation  in  Elf.  Section  4.1  informally  describes  the  transformation  and  shows  how 
to  formalize  a  simple  version  of  it  in  Elf  and  apply  it  to  a  proof.  This  rather  naive  formulation 
needs  improvements  described  in  subsequent  sections.  Section  4.2  describes  how  to  avoid  gener¬ 
ating  detours  in  the  result  proof  that  require  the  application  of  expensive  proof  normalizations. 
Section  4.3  discusses  modifications  to  the  encoding  for  the  suppression  of  unwanted  computation 
in  the  extracted  program. 


4.1  Tail  recursion  introduction 

A  well-known  programming  strategy  for  the  improvement  of  a  recursive  function  definition  is  the 
introduction  of  an  accumulator  argument  to  achieve  a  tail-recursive  form,  which  can  be  compiled 
to  a  loop.  This  strategy  has  long  been  studied  by  researchers  in  transformational  programming,  for 
example  in  [BD77],  [Bir84],  and  many  others.  There  is  a  transformation  that  performs  the  analogous 
optimization  at  the  level  of  proofs;  its  application  to  a  small  example  program  shows  that  in  some 
cases  the  proof  transformation  can  perform  more  optimization  than  techniques  restricted  to  the 
program  level. 

4.1.1  Language  extensions 

In  order  to  work  out  the  example  it  is  necessary  to  add  a  small  theory  of  lists  of  natural  numbers 
to  the  logic,  and  to  extend  the  theory  of  natural  numbers.  These  theories  are  somewhat  ad  hoc, 
and  are  selected  for  convenience  in  working  out  this  particular  example.  This  is  a  result  of  the  very 
limited  capabilities  of  the  base  system,  which  does  not  support  inductive  definitions,  unlike  fully 
developed  systems  like  Nuprl  and  Coq.  The  extended  logic  is  a  many-sorted  first-order  logic  with 
sorts  {nats, lists},  where  lists  are  monomorphic.  This  is  obtained  by  modifying  and  extending  the 
abstract  syntax  of  the  core  logic  (page  17).  The  modification  is  simple:  the  individual  variables  x 
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become  sort-annotated  variables  i',  and  the  equality  symbol  and  quantifiers  are  also  sort-annotated 
(=,, Vi, 3,).  The  logical  syntax  is  then  extended  as  follows: 


Individuals  t 
Lists  I  ::= 

Propositions  A  ::  = 


I  pred  t  j  <1  -  <2  I  signum  t  I  tl>t2 
[  []  I  t  :-.l  I  if  t  then  l\  else  1-2 

1  .  A  i  1  /,  /2  1  tel 


The  predecessor  function  is  denoted  by  “pred”.  The  signum  operator  is  used  to  build  conditional 
functions;  signum  x  =  0  if  and  only  if  x  =  0  and  signum  x  =  1  if  and  only  if  x  /  0.  This  is 
used  to  axiornatize  >  as  a  function  on  natural  numbers,  which  in  conjunction  with  the  list-valued 
arithmetic  switch  (if-then-else)  permits  the  construction  of  the  conditional  function  needed  for  the 
example  of  this  chapter.  The  syntax  for  lists  is  ML-like,  with  []  denoting  the  empty  list  and  :: 
denoting  the  cons  operator. 

Figures  4.1  and  4.2  show  the  inference  rules  for  the  sorts  of  natural  numbers  and  lists  used  in  the 
formalization  of  the  proofs  for  the  example.  Inference  rules  for  equality  and  quantifiers  over  lists 
are  omitted  since  they  are  identical  to  those  for  natural  numbers  except  for  the  sort.  List  induction 
is  parametric  in  l'  and  x';  thus  neither  parameter  may  occur  free  in  any  open  assumption  on  which 
1  II/'')A  or  [x‘  ::  l^/l^\A  depends.  For  the  remainder  of  the  chapter  we  omit  sort  annotations 
whenever  the  context  makes  the  intended  sort  clear. 

The  programming  language  is  extended  accordingly.  Extraction  of  programs  from  proofj  is  not 
difficult  to  extend  to  the  new  language.  There  are  now  three  primitive  relations  -  equalities  for 
natural  numbers  and  lists,  and  the  list  membership  relation;  these  are  all  considered  uninformative 
for  the  purposes  of  extraction. 


...  I  []  I  c,:;e2  | 

list_ind(ei;  x,y,z.e2)  | 
ei  -  €2  I 
ei  >€2  I 

if  Cl  then  €2  else  ej 


Lists 

Primitive  recursioji  on  lists 

Subtraction 

Comparison 

Arithmetic  switch 


For  the  sake  of  readability  the  programs  of  this  chapter  are  shown  in  ML  syntax.  A  straightforward 
mechanical  translation  can  be  defined,  but  we  also  freely  rename  variables,  introduce  let-bindings, 
and  use  pattern- matching.  Natural  numbers  are  represented  as  ML  integers,  and  lists  as  ML  lists. 
Pairs  are  represented  as  ML  tuples;  fst(e)  and  snd(e)  correspond  to  ML  #1  e  and  #2  e.  A  primitive 
recursion  over  natural  numbers  nat_ind(ci;  x,y.e2)  is  represented  as 

fun  f  0  =  el 

I  f  n  =  let  val  y  =  (f  (n-1))  in  e2  end 


where  f  is  a  new  variable,  and  ci  is  represented  as  el  and  62  as  e2.  Primitive  recursion  over 
lists  is  translated  analogously.  The  union  type  r]|r2  with  its  injection  constructors  ini  and  inr  is 
represented  by  the  following  datatype  definition: 

datatype  (’a,  ’b)  union  =  ini  of  'a  |  inr  of  ’b; 
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[t2lh\A 


- PredZ 

pred  zero  =j  zero 


- PredS 

pred  succ  t  =,  t 


- SubZ 

t  -  zero  =i  t 


- Subs 

-  SUCC  t2  =i  pred  (ti  -  <2) 


- Signum 

signum  t  =,  (succ  zero)  —  ((succ  zero)  -  t) 


GGq 

>  h  =i  signum  (<2  -  h) 


Figure  4.1:  Extension  to  theory  of  natural  numbers 


87 


-P 

A 


[  []//V  W  •••• 

- LINDp 

V/.>1 


- AXnil 

-><6  0 


- AXhd 


ti  £  I 
ti  £  ti  ::  I 


AXtl 


- P 

x'  6  I 


ti  £  t2  ::l  {t2hi]A 
A 


Wlh]A 

- €B 


- LSz 

(if  zero  then  li  else  /2)  =  l\ 


- LSs 

(if  (succ  zero)  then  l\  else  h)  =  h 


Figure  4.2:  Fragment  of  a  theory  of  lists  of  natural  numbers 


Elf  encodings  of  these  language  extensions  and  the  extracted  programs  of  this  chapter  are  given 
in  Appendix  D  and  Appendix  E. 

4.1.2  A  simple  proof  and  program 

The  presentation  of  the  tail  recursion  proof  transformation  is  organized  around  a  small  example:  a 
program  to  select  all  elements  of  a  list  that  satisfy  some  constraint.  For  concreteness  and  simplicity, 
it  is  expedient  to  fix  the  selection  criterion  for  the  example  program,  and  develop  a  function  that, 
given  a  list  I  of  natural  numbers,  computes  a  list  of  all  elements  of  /  that  are  at  least  2.  Following 
is  the  specification  with  a  simple  proof. 

Specification  4.1 


V/ .  3r .  [Vj/ .  2/  6  r  (j/  €  /  A  y  >  2)] 

Proof  4.2  The  proof  is  by  induction  on  the  list  /.  If  I  is  empty,  choose  r  to  be  empty  as  well. 
Otherwise  I  —  x  ::  I'  and,  by  the  induction  hypothesis,  there  is  an  r'  such  that  Vy .  y  e  r'  (y  € 
I'  A  y  >  2).  Then  if  x  >  2  let  r  be  a: ::  r';  otherwise  let  r  be  r'.  □ 

The  following  program  is  extracted  from  a  formalized  version  of  the  proof: 

Program  4.3 

fun  select  []  ®  [] 

I  select  (x::l)  = 

let  val  r  =  (select  1)  in 
if  X  >=  2  then  x: ;r  else  r 
end 


This  can  easily  be  transformed  at  the  program  level  to  tail-recursive  form  using  the  fold-unfold 
system  [BD77].  One  introduces  an  auxiliary  function  with  an  extra  “accumulator”  argument  that 
builds  up  the  result  as  control  is  passed  down  the  chain  of  recursive  calls.  Here  is  a  sketch  of  the 
fold-unfold  method  (4  is  the  ML  list  append  operator). 

First  define  an  auxiliary  function  with  accumulator  argument  k. 
fun  sel  Iks  k4(select  1) 


Unfold  the  definition  of  select  in  the  body  of  sel: 
fvm  sel  □  k  =  kcn 

I  sel  (x::l)  k  =  k4(if  x  >=  2  then  x:: (select  1) 

else  (select  1)) 


Then  equational  reasoning  yields: 
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fun  sel  □  k  =  k 

I  sel  (x::l)  k  =  if  x  >=  2  then  (k«[x] )«(8elect  1) 
else  kC (select  1) 

Folding  yields  a  new  recursive  definition  of  sel;  the  original  function  select  can  now  be  defined 
in  terms  of  it: 

Program  4.4 

fun  sel  □  k  =  k 

I  sel  (x: :1)  k  =  if  X  >*  2  then  (sel  1  (k«[x])) 
else  (sel  1  k) 

fun  select  1  =  sel  1  [] 

The  transformed  definition  of  sel  is  tail-recursive,  but  is  inefficient  since  it  uses  the  append 
function.  There  is  a  similar  development  that  shifts  the  inefficiency  to  the  base  case  of  the  recursion, 
giving: 

fun  sel  Ok-  (reverse  k) 

I  sel  (x::l)  k  ®  if  x  >*  2  then  (sel  1  (x::k)) 
else  (sel  1  k) 

where  reverse  is  defined  in  the  obvious  way. 

The  specification  requires  only  that  the  result  contain  the  elements  of  I  that  are  at  least  2,  so 
sel  could  equally  well  be  defined  to  accumulate  its  result  via  the  recursive  call  sel  1’  (x:  :k), 
without  reversing  the  result  list.  But  since  this  change  does  not  preserve  functional  equivalence, 
it  is  not  straightforward  to  accomplish  via  purely  syntactic  program  transformation.  One  could 
avoid  the  difficulty  by  observing  that  /  is  treated  here  as  a  set,  not  a  list,  and  working  in  a  more 
appropriate  algebra.  Depending  on  the  context  in  which  the  function  is  used,  this  may  or  may 
not  be  easy  to  do.  The  use  of  a  proof  transformation  yields  a  similar  tail-recursive  program  that 
computes  with  lists  but  does  not  use  the  append  or  reverse  functions. 

4.1.3  Informal  description 

How  might  one  transform  Proof  4.2  to  obtain  a  proof  whose  realizing  program  is  tail-recursive?  In  a 
constructive  proof  of  VI  .3r.  $(/,  r)  by  list  induction,  the  inductive  step  must  construct  some  term 
t  such  that  for  arbitrary  x,  ^(x  ::  l,t),  using  the  induction  hypothesis  3r'.$(/, r')  as  a  premise. 
The  term  t  corresponds  to  the  value  that  is  returned  by  the  extracted  program.  A  recursive  call  in 
the  program  is  extracted  from  a  use  of  the  induction  hypothesis  in  the  proof.  A  program  is  tail- 
recursive  when  it  does  no  computation  with  the  results  of  its  recursive  calls.  Correspondingly,  an 
inductive  proof  is  realized  by  a  tail-recursive  program  when  the  term  t  is  identical  to  the  parameter 
r'  of  the  induction  hypothesis.  That  is,  if  the  proof  appeals  to  the  induction  hypothesis  to  obtain 
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a  parameter  r'  satisfying  the  specification  for  /,  and  shows  that  the  same  value  r'  also  satisfies  the 
specification  for  x  ::  I  for  any  x,  the  extracted  function  is  tail-recursive.  An  induction  proof  whose 
extracted  program  is  tail-recursive  is  tail-inductive. 

In  Appendix  C  we  give  an  Elf  program  to  recognize  tail-recursive  object  programs,  and  discuss 
the  partial  representation  in  Elf  of  a  proof  that  the  transformation  of  this  chapter  yields  a  tail- 
recursive  program  if  it  succeeds. 

For  example,  Proof  4.2  appeals  to  the  induction  hypothesis  with  I'  for  /  to  obtain  r'  such  that 
'iy  .y  £  r'  {y  ^  V  A  y  >  2);  this  corresponds  to  the  recursive  call  select  1  in  the  extracted 
program.  The  program  is  not  tail  recursive  because  in  the  case  that  x  >2,r'  does  not  satisfy  the 
specification  for  x  I'  and  the  proof  constructs  the  term  x  ::  t‘.  This  construction  corresponds  to 
the  computation  (x:  :r)  (where  r  is  bound  to  the  result  of  the  recursive  call)  in  the  program. 

To  find  a  tail-inductive  proof,  it  is  necessary  to  modify  the  induction  hypothesis.  That  is,  a 
new  specification  is  needed  that  implies  the  original  one.  The  proof  of  the  new  specification  is 
an  inductive  subproof  that  corresponds  to  the  auxiliary  function  definition  sel  of  the  fold-unfo)d 
derivation.  However,  much  of  the  new  inductive  subproof  consists  of  inferences  from  the  original 
induction  proof:  it  is  built  by  a  form  of  lemma  insertion  [Pfe90] . 

Lemma  insertion  is  the  process  of  inserting  new  inferences  (proofs  of  lemmas)  into  a  given  proof 
in  such  a  way  that  the  new  proof  is  valid  if  the  original  proofs  and  the  new  inferences  are  valid. 
Perhaps  the  simplest  example  of  such  a  transformation  is  the  following:  given  a  proof  Ii  of  $  D  $ 
and  a  proof  I2  of  ^  D  $,  we  can  transform 

V 

$ 

to 

V  Ii 

:  :  I2 

$  $  3  $  : 

'5  $  D  $ 

$ 

This  is  an  example  of  a  proof  transformation  that  does  not  change  the  specification  $,  but  only 
the  method  of  proof,  which  determines  the  form  of  the  implementation.  The  correctness  of  the 
transformation  is  a  trivial  meta-theorem  for  any  useful  formalization  of  the  proof  system.  The 
transformed  proof  has  a  different  computational  content  than  the  original  one.  It  still  contains  all 
the  original  computational  content  (since  I?  is  a  subproof);  typically  proof  reduction  is  applied  after 
lemma  insertion  in  order  to  remove  redundant  computational  content  and  obtain  a  program  with 
different  properties.  Thus  lemma  insertion  is  analogous  to  the  definition  of  an  auxiliary  function 
followed  by  unfolding  in  a  program  derivation  in  the  fold-unfold  system  [BD77].  It  creates  a  context 
that  is  exploited  by  subsequent  transformations. 

Lemma  insertion  and  proof  reduction  by  themselves  determine  nothing  about  program  develop¬ 
ment  -  it  is  the  choice  of  lemmas  and  of  proof  methods  that  express  programming  knowledge.  The 
formalization/implementation  of  tail  recursion  introduction  presented  here  does  not  capture  all  of 
the  programming  knowledge  involved:  it  introduces  an  improved  recursion  structure  if  the  user  can 
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provide  the  right  lemmas  and  proofs  for  insertion.  By  expressing  some  minimum  requirements  for 
the  form  of  these  lemmas  and  proofs  it  can  provide  some  guidance  to  a  user,  reducing  the  search 
space  for  a  solution. 

Thus  before  the  lemma  insertion  transformation  can  be  applied,  some  insight  and  knowledge  of 
the  problem  domain  must  be  applied  to  invent  the  right  lemmas  and  their  proofs. 

First,  it  is  necessary  to  find  a  function  h  that  accumulates  the  desired  result  of  the  computation 
in  an  auxiliary  argument  k  as  computation  descends  through  the  recursive  call  sequence.  Suppose 
the  original  proof  concludes  V/.3r.$(/,r)  where  /  and  r  are  lists.  Then  h  should  take  the  result 
k  accumulated  so  far  for  /  and  combine  it  with  the  head  x  of  the  current  list  so  that  $(/,  k)  D 
$(/  o  [a:],h(x,  A:))(where  o  stands  for  the  list  append  operation).  Somewhat  unexpectedly,  a  proof 
of  this  implication  is  not  required  for  the  proof  transformation;  it  is  only  a  guide  to  the  choice 
of  h.  This  choice  can  often  be  “read  off”  from  the  original  proof.  Since  the  original  proof  is  not 
tail-inductive,  there  is  a  term  f{x,r)  that  plays  a  crucial  role  in  the  inductive  step.  The  proof 
appeals  to  the  induction  hypothesis  to  obtain  a  parameter  r  such  that  $(/,r),  and  then  constructs 
/(x,r)  such  that  for  all  x  $(x  ::  /,/(x,r)).  If  $(/,  r)  does  not  depend  on  the  order  of  elements  in  / 
and  r  then  h  =  /  is  an  acceptable  choice. 

The  second  preparatory  step  is  to  choose  a  formula  '9>{k^r,s)  that  expresses  the  fact  that  k  is 
an  accumulator  argument  and  s  is  the  new  final  result.  The  transformed  proof  will  prove 

V/ .  VA: .  3s .  3r .  $(/,  r)  A  ’9{k,r,s) 

by  an  induction  obtained  by  lemma  insertion  from  the  original  induction.  From  this  will  follow 
V/ .  3r .  $(/,r),  but  not  by  the  obvious  trivial  method  of  eliminations.  This  part  of  the  proof  will 
show  that  for  an  appropriate  initial  term  ko,  follows  from  $(/,r)  A  ^(Aro,r,s);  thus  the 

tail-recursive  computation  of  s  can  replace  the  non-tail-recursive  computation  of  r.  This  is  stated 
more  precisely  below. 

A  simple  choice  for  $(A;,r,s)  is  s  =  r  -f-  A:  where  is  chosen  from  an  algebra  appropriate  to 
the  problem  domain.  This  can  often  be  done  -  perhaps  always,  if  one  is  willing  to  shift  the  problem 
specification  to  another  algebra  -  but  it  is  not  required;  equality  is  often  more  than  is  needed. 
need  only  express  a  relation  for  which  three  crucial  lemmas  hold.  Informally  these  are: 

1.  There  is  a  value  ko  such  that  if  $(I,r)  A  9{ko,r,s)  then  $(/, s),  for  any  r,  s,  and  /.  This 
ensures  that  the  new  computation  satisfies  the  old  specification. 

2.  If  ’9{h{x,k),r,s)  then  9{k,  f{x,r),s).  This  is  the  crucial  requirement  for  achieving  tail  recur¬ 
sion.  It  ensures  that  in  an  induction  step  for  V/ .  VA: .  3s  .  3r .  $(/,  r)  A  9{k,  r,  s)  a  parameter 
s  given  by  the  induction  hypothesis  for  I  also  satisfies  the  conclusion  for  x 

3.  There  is  a  function  so(A:)  such  that  ^(k,ro,so{k))  for  all  k,  where  tq  is  the  term  that  witnesses 
the  existence  proof  for  the  base  case  of  the  original  proof.  In  all  our  examples  so{k)  =  k. 

If  the  select  example  were  posed  in  terms  of  sets  rather  than  lists,  a  good  choice  of  ^{k,r,s) 
would  be  (s  =  r  U  A:).  In  that  case  the  proof  would  proceed  by  structural  induction  on  a  type 
of  finite  sets  with  constructor  1+)  (so  rW  {x}  denotes  the  disjoint  union  of  r  and  {t}).  In  this 
formulation  f{x,r)  =  rW  {x};  choosing  h(x,k)  =  {x}  W  A:  makes  it  trivial  to  show  the  crucial  step 
s  =  (rW{x})uA:  from  s  =  rU({x}li)A:)  using  the  associativity  of  set  union.  Whenever  $  can 
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be  expressed  as  an  equality  s  =  F{k,r)  the  crucial  requirement  2  above  becomes  F{h{x,k),r)  = 
F{k,f{x,r)).  A  comparison  with  Bird’s  analysis  (Bir84]  of  general  accumulation  strategies  in 
program  transformation  shows  that  this  requirement  is  a  special  case  of  a  “continuity  condition” 
for  the  accumulation  strategy;  when  this  case  holds,  the  strategy  results  in  a  tail-recursive  program. 
Thus  if  can  be  expressed  as  an  equality,  pure  program  transformation  techniques  have  the  same 
power  as  the  proof  transformation  described  here. 

Since  the  example  is  posed  in  terms  of  lists  instead  of  sets,  it  is  not  possible  to  use  equality  and 
for  this  example  proof  transformation  accomplishes  more  than  syntactic  program  transformation. 

Once  the  lemmas  are  formulated  and  proved,  the  rest  of  the  transformation  is  mechanical,  and 
can  be  implemented  in  Elf  as  a  rewrite  rule.  The  rest  of  this  section  is  a  description  of  the  rule  in 
terms  of  proof  schemas,  with  its  application  to  the  select  example.  The  following  section  gives  its 
formalization  and  implementation  in  Elf. 

The  original  induction  proof  has  the  following  form: 

Proof  schema  4.5 


3r.$([],r) 


- q 


Vs 

^{x  ::/,f(x,r)) 

- p  - 31 

3r.$(/,  r)  3r  .^{x  ::  l,r) 


3r.#(a; ::  l,r) 

- LINDP 

Vf  .3r.#(/,r) 


In  this  schema  boldface  symbols  are  (possibly  higher-order)  pattern  variables.  Where  a  pattern 
variable  is  applied  to  some  terms  . . .  t,-  as  in  #(/,  r),  the  whole  application  is  a  pattern  in  which  the 
terms  ti . .. ti  may  occur  free.  The  font  used  for  the  pattern  variable  indicates  whether  the  pattern 
may  match  a  formula  (upper-case  Greek  letters),  an  individual  (Roman  letters,  e.g.,  f(a:,r)),  or  a 
part  of  a  proof  (script  style  capitals,  e.g.,  V)  in  the  object  logic.  A  schema  of  the  form 

V 


matches  an  object  proof  ending  in  a  formula  'i';  any  variables  free  in  may  also  occur  free  in  V. 
Similarly  a  schema  of  the  form 

V 
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matches  a  proof  fragment  that  depends  on  'i'  and  has  as  conclusion;  any  variables  free  in  ’J'  or 
'if'  may  occur  free  in  T>.  Ordinary  italic  letters  stand  for  bound  variables  and  parameters  of  the 
object  logic. 

For  the  select  example,  #(/,r)  matches  Vy.y  €  r  ^  (y  G  /  A  y  >  2).  Note  that  higher-order 
patterns  respect  the  binding  properties  of  the  object  language.  Thus  in  =  Vy  .y  6  <2 

(y  €  A  y  >  2),  y  may  not  occur  free  in  or  <2-  In  the  Elf  implementation  the  use  of  function 
objects  in  the  LF  calculus  to  represent  higher-order  patterns,  in  combination  with  higher-order 
abstract  syntax,  enforces  this  restriction.  When  the  meaning  is  clear  from  context,  we  will  write 
“the  term  t”  to  mean  a  term  that  matches  the  pattern  t,  and  similarly  for  formulas  and  proofs. 

The  next  three  schemas  describe  the  lemmas  concerned  with  the  auxiliary  specification  'J,  which 
expresses  the  relation  between  the  original  result  r,  the  accumulator  argument  k,  and  the  new  result 
s. 


1.  To  recover  the  original  specification  from  the  new  conclusion  of  the  induction  the  transfor¬ 
mation  requires  a  proof  Xr,  of 

Lemma  schema  4.6  (Recovery  lemma) 

V/.Vr.Vs.($(/,r)  A  ’i'(ko,r,s))  D  $(/,s) 


for  some  term  Icq. 

For  the  select  example  ’if{k,r,s)  is  Vy.y  €  s  (y  €  r  V  y  €  fc);  thus  the  transformed 
induction  sub-proof  will  prove: 

Specification  4.7 

V/ .  VA: .  3s .  3r .  [Vy .  y  G  r  (y  G  /  A  y  >  2)]  A  [Vy .  y  G  s  <!=►  (y  G  r  V  y  Q  k)] 

The  term  ko  is  the  empty  list  [],  and  it  is  easy  to  show 

V/ .  Vr .  Vs .  [(Vy  .y  £  r  {y  Q  I  A  y>2))  A  (Vy  .yGs^(yGr  V  yG  []))]  D 

Vy  .y  G  s  -»■  (y  G  /  A  y  >  2) 

Operationally  this  proof  corresponds  to  a  redefinition  of  the  original  function  in  terms  of  an 
auxiliary  function  which  is  extracted  from  the  induction  subproof.  It  determines  an  initial 
value  ko  for  the  accumulator  argument  k. 

2.  The  second  obligation  imposed  by  the  transformation  is  a  proof  Xg  of 

Lemma  schema  4.8  (Inductive  case  lemma) 

Vx.Vfe.Vr.Vs  . ^(h(x,A:),r,s)  D  ^(A:,f(x,r),s) 

where  the  pattern  f(x,r)  is  given  by  the  original  proof  matching  Schema  4-5  and  the  pattern 
h(x,A:)  is  supplied  by  the  user. 
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For  the  select  example,  f(i,r)  =  if  a:  >  2  then  x  v.  r  else  r.  Choosing  h{x,k)  =  it  x  > 
2  then  x  ::  k  else  k  leads  to  the  following  lemma,  which  is  easily  proved: 

Vi.Vit.Vr.Vs.(Vj/.y  £  s  {y  €  r  V  y6(ifar>2  then  x  ::  k  else  k)))  D 
(Vj/ .  y  €  s  (y  G  (if  x  >  2  then  x  ::  r  else  r)  V  y  €  k)) 


Viewed  operationally,  h  determines  the  value  bound  to  the  accumulator  argument  k  in  the 
recursive  call  of  the  extracted  program. 

3.  For  the  base  case  of  the  new  inductive  subproof,  the  transformation  requires  a  proof  of 

Lemma  schema  4.9  (Base  case  lemma) 

VA:.^'(fc,ro,so(Ar)) 

ro  is  the  witness  term  for  the  base  case  of  the  original  proof  matching  Schema  4.5;  sq  is 
supplied  by  the  user. 

Operationally,  so(/i:)  is  the  value  that  will  be  returned  in  the  base  case  of  the  recursion. 

For  the  list  selection  example,  r©  is  the  empty  list  [],  since  that  is  the  witness  for  the  base 
case  in  Proof  4.2.  No  further  processing  is  needed  of  the  value  accumulated  in  k,  so  we  choose 
the  identity  function  for  lists  as  the  value  for  sq.  Then,  applying  Specification  4.7,  we  have 
'9(k,  [],  A:)  =  Vy .  y  €  /i:  ^  (y  €  0  V  y  £  k),  which  is  trivial  to  prove  for  all  k. 

The  proof  transformation  inserts  the  proof  X-q  into  the  base  case  subproof  of  the  original  proof, 
the  proof  Zs  into  the  step  case  subproof,  and  constructs  a  proof  of  the  original  specification  from 
the  new  specification  using  the  proof  Xr.  The  result  has  the  following  form: 

Proof  schema  4.10 


$(/,r)  A  ^'(^x, A:),r,s) 


■Ps' 

#(x  :: /,f(x,r))  A  'i'(fc,f(x,r),s) 

Vfc .  3s .  3r .  #([],r)  A  'if{k,r,s)  Vfc .  3s .  3r .  #(x  :: /, r)  A  ’J'(A:, r, s) 

V/.VA:.3s.3r.$(/,r)  A  '^(fc, r,s) 


LIND* 


V/.3r.$(/,r) 
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I>B'  is  constructed  from  'Pb  of  Proof  schema  4.5  and  Xb;  Ps'  from  Pg  and  Xg,  and  Pr  from 
Xr  in  the  obvious  way.  We  use  double  horizontal  lines  in  the  schema  to  elide  trivial  quantifier 
elimination  and  introduction  steps. 

The  following  is  an  informal  statement  of  the  new  proof  of  Specification  4.1  obtained  by  applying 
this  transformation  to  the  select  example: 

Proof  4.11  We  first  show 

V/ .  Vfc .  3s .  3r  .  [Vy  .y€r^(y6  /  A  y>2)]  A  [Vy .  y  6  s  ^  (y  G  r  V  y  €  A:)] 

by  induction  on  /.  If  /  =  []  then  choose  s  =  k  and  r  =  [].  Otherwise  I  =  x  ::  I'.  If  a:  >  2,  then  by 
instantiating  the  induction  hypothesis  with  /'  and  x  ::  k,  we  obtain  a  list  r'  containing  all  elements 
>  2  of  /'  and  a  list  s'  containing  all  the  elements  of  r'  and  x  ::  k.  Then  choose  r  =  x  ::  r'  and 
s  =  s'.  Otherwise  ->x  >  2;  again  by  the  induction  hypothesis  there  is  a  list  r'  as  before,  and  a  list 
s'  containing  all  the  elements  of  r'  and  k.  Let  r  =  r'  and  s  =  s'. 

Now  for  any  list  /,  there  are  lists  s,r  such  that 

[Vy  .y  e  r  (y  €  /  A  y  >  2)]  A  [Vy  .y  G  s  o  (y  G  r  V  y  G  [])] 

Since  s  contains  exactly  the  elements  of  r,  we  have 

Vy.y  G  s  •«>  (y  G  /  A  y  >  2) 


and 

V/ .  3r  .  [Vy .  y  G  r  (y  G  /  A  y  >  2)] 

□ 


The  form  of  the  inductive  reasoning  in  this  proof  determines  a  tail- recursive  computation,  but 
only  for  the  parameter  s:  the  term  s'  given  by  the  induction  hypothesis  for  /',  x  ::  k  satisfies 
the  specification  for  x  ::  /',  k,  but  the  term  r'  does  not;  we  must  construct  a:  ::  r'  as  witness  for 
the  inner  existential  quantifier.  To  look  at  it  another  way,  we  have  developed  a  program  that 
computes  the  answer  we  want  twice:  once  by  the  original,  non-tail-recursive  method,  and  once  by 
a  new  method  that  (on  its  own)  is  tail-recursive.  Thus  it  may  seem  that  the  transformation  has 
not  accomplished  anything!  However,  there  is  a  proof  transformation  that  removes  the  unwanted 
computation  associated  with  the  inner  existential  quantifier.  This  transformation  is  quite  general 
and  does  not  impose  any  further  proof  obligations  on  the  user.  It  introduces  a  double  negation  to 
produce  an  inductive  proof  of  the  following: 

V/ .  VA: .  3s .  -i-i3r .  [Vy  .yGr4^(yG  /  A  y>2)]  A  [Vy .  y  6  s  o  (y  G  r  V  y  E  k)] 

Section  4.3  discusses  this  transformation  in  detail. 

The  rest  of  this  chapter  describes  the  implementation  of  the  transformation.  Applied  to  the 
example  the  implementation  yields  the  following  extracted  program: 


Program  4.12 
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fun  sel  1  » 

let  fun  sel’  nil  =  (fn  k  =>  k) 

I  sel*  (x::l’)  =  let  val  p  =  (sel*  1*)  in 

fn  k  ®>  (p  (if  X  >=  2  then  (x::k)  else  k))  end 
in  (sel’  1  nil) 
end; 


Like  the  result  of  the  fold-unfold  derivation  (Program  4.4),  this  program  is  tail-recursive.  But  it  is 
more  efficient  because  the  partial  result  is  accumulated  by  the  application  of  the  list  constructor 
instead  of  the  append  function.  The  difference  is  a  consequence  of  working  with  the  specification 
and  its  proof  throughout  the  development  rather  than  restricting  the  reasoning  to  the  properties 
of  the  program  <ilone.  It  is  an  instance  of  the  phenomenon  noted  by  Goad  [GoaSO]:  using  proof 
transformation  he  demonstrated  that  a  program  can  be  specialized  to  a  particular  class  of  input 
values  by  exploiting  the  fact  that  there  is  no  need  to  preserve  functional  equivalence  of  the  successive 
stages  of  program  development. 

4.1.4  Formalization 

The  first  step  in  the  formalization  of  the  transformation  is  to  declare  a  judgment  that  relates  the 
input  proofs  and  individual  terms  to  the  output  proof.  By  giving  the  types  of  the  terms  related  by 
the  judgment  the  declaration  provides  static  (type-checking  time)  correctness  guarantees.  (For  the 
Elf  syntax  of  lists  and  list  quantification  see  Figure  4.3.) 

tail.rec  : 

•CRO}  {SO}  {K0>  {F}  {H} 

{Phi:  ilist  ->  ilist  ->  o} 

{Psi:  ilist  ->  ilist  ->  ilist  ->  o} 

%%  Input  proof: 

I-  (Iforall  [1]  lexists  [r]  (Phi  1  r)) 

VI*  Base  case  lemma: 

->  I-  (Iforall  [k]  Psi  k  RO  (SO  k)) 

%7t  Inductive  case  lemma: 

->  I-  (forall  [x]  Iforall  [k]  Iforall  [r]  Iforall  [s] 
implies  (Psi  (H  x  k)  r  s)  (Psi  k  (F  x  r)  s)) 

Recovery  lemma: 

->  I-  (Iforall  [1]  Iforall  [r]  Iforall  [s] 

implies  (and  (Phi  1  r)  (Psi  KO  r  s))  (Phi  Is)) 

VI,  Output  proof: 

->  |-  (Iforall  [1]  lexists  [r]  (Phi  1  r)) 

->  type. 


The  logic  variables  in  the  declaration  correspond  to  the  pattern  variables  of  the  proof  and  lemma 
schemas  of  the  previous  section;  e.g.,  RO  corresponds  to  the  pattern  variable  tq,  Phi  corresponds 


ilist  :  type, 
nl  :  ilist. 

cns  :  i  ->  ilist  ->  ilist. 

leq  :  ilist  ->  ilist  ->  o. 

Iforall  :  (ilist  ->  o)  ->  o. 
lexists  :  (ilist  ->  o)  ->  o. 


%lists  of  natural  numbers 

*/, empty  list 
*/,cons 

*/, equality  for  lists 

'/.universal  quantifier 
y.existential  quantifier 


Iforalli  :  ({x: ilist}  I-  (Ax))  ->  |-  (Iforall  A). 
Iforalle  :  {T: ilist}  I-  (Iforall  A)  ->  |-  (A  T) . 


lexistsi  :  {A: ilist  ->  o}  {T: ilist}  |-  (AT)  ->  I-  (lexists  A), 
lexistse  :  ({x: ilist}  I-  (Ax)  ->  |-  C)  ->  |-  (lexists  A)  ->  I-  C. 


lind  :  {A: ilist  ->  o} 

I-  (A  nl) 

->  ({1: ilist}  I-  (A  1)  ->  {x:i}  |-  (A  (cns  x  1))) 
->  I-  (Iforall  A). 


Figure  4.3;  Elf  encoding  of  lists  of  natural  numbers 
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to  and  so  on.  The  types  of  the  individuals  and  functions  on  them  RO  . . .  H  need  not  be  given 
since  the  Elf  type  reconstruction  algorithm  can  infer  them  from  their  contexts  in  the  declaration. 

The  declaration  ensures  that  the  judgment  relates  (a  term  representing)  a  proof  of  VZ .  3r .  ^(/,  r) 
(which  can  be  thought  of  as  an  input),  other  input  terms  representing  individuals,  functions  on 
individuals,  and  the  proofs  of  the  lemmas  to  be  inserted,  and  another  proof  (which  can  be  thought 
of  as  an  output)  of  VZ .  3r .  $(Z,  r)  .  Assuming  that  the  logic  is  correctly  encoded,  if  a  query  of  the 
form  “?-  tail-rec  . . .  <proof-term>  ...  P”  succeeds,  the  LF  type  system  ensures  that  the 
variable  P  is  bound  to  a  term  that  represents  a  valid  proof  of  the  same  proposition. 

The  other  step  in  the  encoding  is  to  write  a  clause  describing  the  forms  of  the  terms  related  by 
the  judgment  tail-rec.  This  can  be  done  by  transcribing  the  schemas  of  the  previous  section  into 
Elf.  We  then  have  a  one-clause  Elf  “program”  that  implements  the  transformation  as  a  rewrite 
rule. 

First  we  encode  Proof  schema  4.5,  which  describes  the  input  proof. 
tl_rec  :  tail.rac 
*/,*/,  Input  proof: 

(lind  ([1]  lexists  [r]  Phi  1  r) 

(lexistsi  ([r]  Phi  nl  r)  RO  Db) 

([1]  Cp:  !“  (lexists  [r]  Phi  1  r)]  [x] 

(lexistse  ([r]  [q:  |-  (Phi  1  r)] 
lexistsi  _  (F  X  r)  (Ds  x  1  r  q)) 
p))) 


For  the  sake  of  readability  this  declaration  includes  some  type  and  term  information  that  can  be 
inferred  by  Elf.  Again  the  upper-case  letters  are  Elf  logic  variables,  and  correspond  to  the  pattern 
variables  of  Proof  schema  4.5.  Thus  for  instance  Ds  corresponds  to  the  subproof  Since  the 
transformation  is  encoded  as  a  pattern  match  with  no  subgoals,  these  variables  are  instantiated 
only  by  higher-order  unification  with  the  object  proof  term  supplied  in  the  query.  Thus  Phi  is 
bound  to  a  function  from  two  lists  to  the  matrix  of  the  IIq  formula  proved,  RO  to  the  list  that 
witnesses  the  base  case  of  the  induction,  Db  to  the  proof  of  the  base  case,  and  so  on. 

Some  care  must  be  taken  when  coding  transformations  this  way  to  avoid  encountering  unification 
problems  that  are  not  solved  by  the  Elf  implementation.  If  an  encoding  restricts  its  use  of  logic 
variables  for  pattern  matching  to  higher-order  patterns  (in  the  sense  of  [PfeQlb]),  only  deterministic 
unification  problems  will  arise  during  execution.  These  problems  fall  within  a  decidable  subcase 
of  higher-order  unification  (which  is  undecidable  in  general),  discovered  by  Miller  [Mil91]  for  the 
simply  typed  lambda  calculus  and  extended  to  LF  by  Pfenning.  The  main  idea  of  the  restriction 
is  that  variables  subject  to  instantiation  during  search  (like  Ds)  should  occur  only  as  generalized 
variables.  Roughly  speaking,  a  generalized  variable  is  a  term  of  the  form  xyi  ...yn  where  x  is 
subject  to  instantiation  and  the  t/,-  are  distinct  bound  variables  (not  subject  to  instantiation).  In 
the  example  above,  the  subterm  Phi  1  r  is  a  generalized  variable,  while  Phi  nl  r  is  not.  The 
latter  term  could  lead  to  nondeterminism  if  unified  with  one  containing  a  logic  variable;  but  this 
does  not  cause  problems  when  the  clause  is  used  as  intended,  that  is,  the  input  proof  and  lemmas 


99 


are  given  as  ground  terms  in  the  query. 

Note  that  the  subproof  T>s  represented  by  a  logic  variable  of  functional  type  in  order  to 
express  the  fact  that  the  parameters  x,  I,  r,  and  q  may  appear  free  in  this  part  of  the  proof. 

The  encodings  for  the  proofs  of  the  three  lemmas  to  be  inserted  are  trivial:  a  logic  variable  for 
each  proof  is  all  that  is  needed.  This  is  because  the  transformation  does  not  depend  on  the  structure 
of  these  proofs.  We  use  Elf  logic  variables  I_b,  I_s,  and  I_r  to  correspond  to  the  pattern  variables 
and  Ir  respectively.  Similarly  the  transformation  does  not  depend  on  the  structure  of 
the  individual  terms  and  the  functions  on  them  (fq  and  so  on),  so  these  too  are  encoded  as  logic 
variables.  The  clause  at  this  stage  reads: 

tl_rec  :  tail_rec 
RO  SO  KO  F  H 
Phi  Psi 

y,y,  Input  proof: 

(lind  ([1]  lexists  [r]  Phi  1  r) 
y.y.  Base  case: 

(lexistsi  (Cr]  Phi  nl  r)  RO  Db) 
y,y,  Step  case: 

([13  [p:  I-  (lexists  [r]  Phi  1  r)3  [x] 

(lexistse  ([r]  [q:  I-  (Phi  1  r)] 
lexistsi  _  (F  X  r)  (Ds  x  1  r  q)) 
p))) 

y,y,  Base  case  lemma: 

I_b 

y,y.  Step  case  lemma; 

I_s 

'/,'/•  Recovery  lemma: 

I_r 


Once  all  the  inputs  are  described  and  named,  the  pattern  of  Proof  schema  4.10,  which  describes 
the  output  proof,  can  be  formalized  and  added  as  the  final  argument  of  the  clause  tl_rec.  Where 
the  schema  elides  the  details  of  how  the  lemmas  are  inserted,  the  formalization  must  give  them 
explicitly. 

Consider  the  base  case  of  the  output  proof.  It  is  assembled  from  the  subproof  of  the  input 
proof  and  the  auxiliary  proof  Xq.  It  must  prove 

VA:  ,3s  .  3r .  ${[],r)  A  '9{k,r,s) 

Since  Ig  proves  VA: .  'if(A:,ro,so(A:))  it  is  necessary  to  eliminate  the  quantifier  before  using  it. 
which  proves  4^([],ro)  can  be  used  directly.  Thus  the  whole  base  case  of  the  new  induction  is 
described  by  the  pattern: 


(Iforalli  [k]  lexistsi  _  (SO  k)  (lexistsi  _  RO  (andi  Db  (Iforalle  k  I_b)))) 
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Similarly  before  using  Jgi  which  proves 

Vi  .  VA: .  Vr .  Vs .  ’i'(h(i,  A;),  r,  s)  D  'i'(A:,  f(i,  r),  s) 
the  transformation  must  perform  eliminations  on  the  induction  hypothesis 

VA: .  3s  .  3r  A  '^(A;,r,s) 

to  obtain  ^'(h(x,  A:),r,  s).  The  implication  derived  from  Is  can  then  be  used  to  obtain  ’4'(A:,f(i,r),s) 
The  subproof  also  needs  $(x  ::  /,f(x,r)),  which  is  obtained  by  again  performing  eliminations  on 
the  induction  hypothesis  and  applying  Ds-  Finally  the  appropriate  quantifiers  must  be  introduced. 
Then  the  step  case  of  the  induction  is  encoded  as: 

[1]  '/•  list  parameter 
[p]  '/.  induction  hypothesis 
[x]  y,  element  parameter 
(Iforalli  [k] 

(lexistse  ([s]  [q’] 

(lexistse  ( [rj  [q] 
lexistsi  _  s 
(lexistsi  _  (F  X  r) 

(andi 

(Ds  X  1  r  (andel  q)) 

(impliese 

(Iforalle  s  (Iforalle  r  (Iforalle  k  (foralle  x  I.s)))) 

(ander  q))))) 

q’)) 

(Iforalle  (H  x  k)  p))) 


For  similar  reasons  in  order  to  use  the  proof  Ir  of 

V/.Vr.Vs.(^(/,r)  A  ^(ko,r,s))  D  #(/,s) 

to  obtain  a  proof  of  the  specification  V/ .  3r .  #(/,  r)  it  is  necessary  to  eliminate  the  quantifiers  before 
the  implication  can  be  used. 

The  whole  clause  defining  the  rewrite  rule  in  Elf  is  shown  in  Figure  4.4.  With  this  clause  and 
formalizations  Psi,  Ib,  Isi  Ir  of  Ib»  respectively,  we  can  transform  a  formalization 

P  of  Proof  4.2  to  a  formalization  of  Proof  4.11  by  submitting  the  following  query  to  Elf: 

?-  tail_rec  RO  SO  F  H  KO  Phi  Psi  P  Ib  h  Ir  Q- 

Here  the  italic  variables  (e.g.,  P)  stand  for  closed  LF  object  terms  provided  by  the  user.  The 
text  in  typewriter  font  (e.g.,  RO)  is  input  as-is  by  the  user;  thus  the  variables  RO. . .Phi  and  Q  are 
Elf  logic  variables.  If  the  query  succeeds  the  Elf  interpreter  displays  the  terms  bound  to  them  in 
the  course  of  the  search.  Note  that  when  the  specification  Psi,  the  input  proof  P  and  the  auxiliary 
proofs  IbiIsi  and  Ir  are  given  as  ground  terms  in  the  query,  it  is  not  necessary  to  provide  terms  for 
RO,  SO,  F,  H,  KO,  or  Phi;  they  are  found  by  unification  in  the  course  of  term  and  type  reconstruction. 
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tl_rec  : 
tail_rec 
RO  SO  KO  F  H 
Phi  Psi 

'!!!%  Input  proof: 

(lind  ([1]  lezists  [r]  Phi  1  r) 

'/,%  Base  case: 

(lexistsi  ([r]  Phi  nl  r)  RO  Db) 

'HU  Step  case: 

([1]  Cp:  I-  (lezists  [r]  Phi  1  r)]  [x] 

(lezistse  ([r]  [q:  |-  (Phi  1  r)] 
lexistsi  _  (F  X  r)  (Ds  x  1  r  q)) 
p))) 

'HI,  Leoaa  proofs: 

I_b  I_s  I_r 
'HU  Output  proof: 

(Iforalli  [1] 

'HU  Recovery  of  original  specification: 
lezistse  (Cs]  Cp’] 
lezistse  ( [r]  [p] 

(lexistsi  _  s  (impliese  (Iforalle  s  (Iforalle  r  (Iforalle  1  I_r)))  p))) 
p’) 

(Iforalle  KO 
(Iforedle  1 

'HU  Hew  inductive  sub-proof: 

(lind  ([1]  Iforall  ([k]  lezists  [s]  lezists  [r]  and  (Phi  1  r)  (Psi  k  r  s))) 

'HU  Base  case: 

(Iforalli  [k]  lexistsi  _  (SO  k)  (lexistsi  _  RO  (andi  Db  (Iforalle  k  I_b)))) 
'HU  Step  case: 

(Cl]  Cp]  Cx] 

(Iforalli  Ck] 

(lezistse  (Cs]  Cq’] 

(lezistse  ( Cr]  Cq] 
lexistsi  _  s 
(lexistsi  _  (F  X  r) 

(andi 

(Ds  X  1  r  (andel  q)) 

(impliese 

(Iforalle  s  (Iforalle  r  (Iforalle  k  (foralle  x  I_s)))) 

(ander  q))))) 

q’)) 

(Iforalle  (H  x  k)  p)))))))). 


Figure  4.4:  Elf  implementation  of  the  tail  recursion  transformation 
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On  the  other  hand,  it  is  necessary  to  give  the  predicate  $  explicitly  because  the  corresponding  logic 
variable  Psi  does  not  occur  as  a  generalized  variable  in  the  declaration  of  the  judgment  tail-rec. 

The  proof  term  bound  to  Q  has  some  undesirable  features.  It  is  likely  to  contain  “detours”:  each 
inserted  lemma  will  typically  be  a  maximum  formula  in  the  sense  of  Prawitz  [Pra71],  being  the 
conclusion  of  an  introduction  rule  and  the  premise  of  the  corresponding  elimination  rule.  These 
detours  are  reflected  in  the  extracted  program  as  redices  like  the  following  fragment,  extracted 
from  the  transformed  list  selection  example  proof.  The  reader  is  not  intended  to  decipher  to 
computational  meaning  of  this;  what  is  important  is  the  appearance  of  the  unreduced  application 
of  the  function  u.  This  reflects  the  quantifier  and  implication  eliminations  immediately  following 
introductions  in  the  source  proof. 


let  fim  u  x’  zl  z2  z3  q  y  = 
case  (q  y)  of  (ini  p’)  =>  ini  () 

I  (inr  p’)  => 

case  (if  x’  >=  2  then  ini  ()  else  inr  ()) 

of  (ini  q’)  =>  if  y  =  x*  then  ini  ()  else  inr  () 
I  (inr  q’)  =>  inr  () 
in 

(s,  (if  X  >=  2  then  x: :r  else  r,  (u  x  k  r  s  p2))) 
end 


The  next  section  discusses  how  to  avoid  introducing  these  detours. 

The  more  serious  defect  is  that,  as  we  mentioned  before,  because  Q  contains  a  proof  of  the 
informative  formula 

V/.Vjfc.3s.3r.^(/,r)  A  ^{k,r,s) 

the  program  extracted  from  Q  must  compute  both  witnesses  r  and  s,  doing  all  the  computation  of 
the  original  program  as  well  as  the  new  computation  introduced  by  the  transformation.  Section  4.3 
describes  how  to  eliminate  the  computation  of  r  by  introducing  double  negations  into  parts  of  the 
inductive  subproof. 


4.2  Suppressing  detours  in  the  output  proof 

Transformations  on  proofs  often  introduce  detours  which  can  be  removed  by  normalization.  But 
since  normalization  is  expensive,  and  may  remove  redices  which  the  user  would  prefer  to  keep,  it  is 
better  to  encode  a  transformation  so  that  it  does  not  introduce  unnecessary  detours  in  the  result 
proof. 

In  the  case  of  the  tail-recursion  transformation,  examining  the  pattern  for  the  output  proof 
shows  that  detours  in  the  form  of  quantifier  or  implication  introductions  immediately  followed  by 
eliminations  are  likely  to  be  introduced  when  the  lemma  proofs  I.b,  I_s,  and  I_r  are  used.  These 
detours  can  be  avoided  by  lifting  the  universal  quantifiers  of  the  object  logic  to  the  meta-level. 
That  is,  the  judgment  takes  schematic  proofs  of  the  lemmas,  represented  as  functions  of  dependent 
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type  from  list  terms  to  proofs.  In  addition,  for  Lemma  schemas  4.6  and  4.8,  we  lift  the  object- 
logic  implication  to  the  meta-level.  Then  the  beta  reductions  performed  by  Elf  in  the  course  of 
producing  canonical  terms  take  the  place  of  explicit  proof  normalization.  The  lifted  representation 
is  faithful  to  the  object  logic;  this  is  a  consequence  of  the  fact  that  constructive  minima)  many-sorted 
predicate  logic  is  representable  in  LF  via  the  propositions- as- types  interpretation,  as  described  in, 
e.g.,  [Bar91].  In  this  interpretation  universal  quantification  in  the  object  logic  is  represented  by 
11- quantification  and  implication  by  simple  function  types. 

We  describe  lifting  for  the  simplest  case  first.  Instead  of  requiring  a  proof  of  Lemma  schema  4.9: 

VA:.'i»(A:,ro,so(A:)) 

we  require  a  function  from  a  term  representing  a  list  to  a  proof  of  the  lemma,  with  type: 

nA;:ilist.  pf  "i'(A:,ro,so(fc)) 


In  Elf’s  concrete  syntax  this  is: 

{k:ilist}  I-  (Psi  k  RO  (SO  k)) 


With  this  representation,  the  pattern  for  the  output  proof  no  longer  needs  the  VE  rule.  Instead 
the  schematic  proof,  represented  as  an  LF  function,  is  applied  to  a  term  to  produce  an  object-level 
proof.  Thus  the  subterm  in  the  original  encoding 

(Iforalle  k  I_b) 


becomes 
(I-b  k) 


Similarly,  the  type  of  the  proof  of  Lemma  schema  4.8  becomes: 

<x}  {k}  {r}  {s}  I-  (Psi  (H  X  k)  r  s)  ->  |-  (Psi  k  (F  x  r)  s) 


Instead  of  the  sequence  of  eliminations 

(impliese  (Iforalle  s  (Iforalle  r  (Iforalle  k  (foralle  x  I_s))))  (ander  q)) 


the  pattern  for  the  output  proof  contains  the  application 
(I_s  X  k  r  s  (ander  q)) 
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tl_r«c  :  tail_rac 
RO  SO  KO  F  H 
Phi  Psi 

%%  Input  prool: 

(lind  (Cl3  lexistB  ([r]  Phi  1  r)) 

XX  Base  case: 

(lexistsi  ([r]  Phi  nl  r)  RO  Ob) 

XX  Step  case: 

([1]  Cp:  I-  (lexists  ([r]  Phi  1  r))]  [x] 

(lexistse  ([r]  Cq:  |-  (Phi  1  r)] 
lexistsi  _  (F  X  r)  (Ds  x  1  r  q)) 
p))) 

XX  Lesusa  proofs: 

I_b  I_s  I_r 
XX  Output  proof: 

(Iforalli  ([1] 

XX  Recovery  of  original  specification: 
lexistse  (Cs]  [p*] 
lexistse  (Cr]  [p] 

(lexistsi  _  s  (I_r  1  r  s  p))) 
p’) 

(Iforidle  KO 
(Iforalle  1 

XX  leu  inductive  sub-proof: 

(lind  ([1]  Iforzai  (Ck]  lexists  ([s]  lexists  ([r]  and  (Phi  1  r)  (Psi  k  r  s))))) 
XX  Base  case: 

(Iforalli  ([k]  lexistsi  _  (SO  k)  (lexistsi  _  RO  (smdi  Db  (I_b  k))))) 

XX  Step  case: 

(Cl]  Cp]  Cx] 

(Iforalli  Ck] 

(lexistse  (Cs]  Cq'] 

(lexistse  ( Cr]  Cq] 
lexistsi  _  8 
(lexistsi  _  (F  X  r) 

(andi  (Ds  x  1  r  (andel  q))  (1_8  x  k  r  s  (ander  q))))) 
q’)) 

(Iforalle  (H  x  k)  p) )))))))). 


Figure  4.5:  Lifted  Elf  implementation  of  tail-recursion 
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lift.all  :  I-  (forall  A)  ->  «x}  1-  (Ax))  ->  typa. 

lift.all.doTO  :  lift. all  (foralli  P)  P. 
lift.all.up  :  lift.all  P  ([x]  foralle  x  P) . 


Figure  4.6:  Correctness  of  lifting 


The  encoding  of  Lemma  schema  4.6  is  treated  in  the  same  way.  The  complete  declaration  of 
the  lifted  form  of  the  judgment  tail-rec  is  shown  in  Figure  4.5. 

The  soundness  of  this  lifting  technique  is  easy  to  see:  from  any  schematic  proof  II  a: .  $  a  proof 
of  Vx .  $  can  be  built  by  the  application  of  the  constructor  VI,  and  a  similar  argument  holds  for 
implication.  Completeness  follows  from  the  observation  that  for  any  proof  F  of  Vx .  $  there  is  a 
schematic  proof  Ax .  (VE  x  F)  of  type  IIx  and  similarly  for  implication.  Correctness  of  lifting 
can  be  formulated  and  proved  very  simply  using  the  techniques  of  Chapter  3.  We  show  the  fragment 
for  the  case  of  universal  quantification  over  terms  of  sort  i  in  Figure  4.6.  The  clause  lif  t_all_down 
shows  soundness  since  it  gives  an  object  proof  for  an  arbitrary  lifted  proof  P,  and  lift_all_up  shows 
completeness,  giving  a  lifted  proof  for  any  object  proof.  The  clauses  defining  lift.all  could  be 
executed  as  proof  transformations  to  lift  arbitrary  given  lemmas,  but  in  the  special  case  (but  in 
practice  a  very  likely  case)  of  a  lemma’s  proof  terminating  in  Vl,  the  clause  lift_all_up  would 
introduce  a  detour  in  the  resulting  proof.  In  this  case  the  proof  P  given  by  lif  t.all-down  is  the 
desired  lifted  version. 

Pragmatically,  the  benefits  of  lifting  are  twofold:  it  improves  efficiency  by  reducing  the  size 
of  the  proof  terms  to  be  processed  during  transformation  and  program  extraction,  and  results 
in  simpler,  more  compact  and  intelligible  encodings  of  transformations.  The  same  technique  has 
been  used  by  Pfenning  [Pfe92a]  in  an  Elf  implementation  of  Plotkin’s  continuation-passing  style 
conversion  [Plo75],  following  an  analysis  by  Danvy  and  Fiiinski  [DF92]. 
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Program  4.13 
fun  sel  1  s 

let  fun  sel’  nil  »  (fn  k  *>  (k,  (nil,  fn  x  =>  inr  ()))) 
I  sel’  (x  ::  1’)  »  let  val  p  =  (sel’  1’)  in 
fn  k  *> 


let  val  (r,  pi)  p  in  s 
end  end  end; 


Figure  4.7:  Superfluous  computation  in  select  example 


4.3  Suppressing  unwanted  computation 

As  we  noted  above,  the  transformed  proof  still  contains  all  the  structure  of  the  original,  including 
the  now  superfluous  inner  existence  proof  for  r.  As  a  result  the  extracted  program  is  still  not  tail- 
recursive.  This  can  be  seen  in  Figure  4.7,  which  shows  the  program  extracted  from  the  proof  for 
the  select  example.  Roughly  speaking,  the  outlined  code  corresponds  to  the  existence  proof  for  r. 
More  precisely,  the  auxiliary  function  sel’  has  type: 

int  list  ->  int  list  ->  int  list  *  (int  list  ♦  (int  ->  (unit, unit)  union)) 


But  all  we  really  need  is  int  list  ->  int  list  ->  int  list;  the  extra  structure  is  generated 
by  the  existence  proof  for  r.  (Removing  uninformative  terms  during  extraction  does  not  help  here 
because  the  presence  of  an  existential  quantifler  and  a  disjunction  in  the  specification  makes  it 
“informative”.)  To  avoid  the  unwanted  computation,  we  further  transform  the  inductive  subproof 
to  obtain  a  proof  of 

V/.Vfe.3s.-i-'3r.$(/,r)  A  'f(fc,r,s) 

Introducing  the  double  negation  of  the  existential  quantifier  for  r  prevents  the  extraction  of  a 
program  to  compute  r,  since  we  have  defined  negative  formulas  as  uninformative. 

The  double  negation  introduction  can  be  done  easily  since  the  following  are  derived  rules  of  the 
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object  logic: 


A 

--A 

Their  derivations  give  the  needed  proof  transformations  in  the  form  of  rewrite  rules.  These  are 
applied  to  the  appropriate  subproofs  -  those  that  have  3r .  $(t,  r)  for  some  term  t  -  as  the  output 
proof  is  constructed. 

First,  given  a  closed  proof  V  with  end-formula  A,  transform  V  to: 

Proof  schema  4.14 


—  P 

-^A  A 

- lE 

X 

—  -IP 


Similarly,  given  an  open  proof  depending  on  the  premise  A: 

A 

V 

B 


transform  it  to: 
Proof  schema  4.15 


-P 

A 


V 

- 9  ■ 

B 

- .E 

X 

— .IP 

-i-'A  -lA 

- .E 

X 

- .1’ 

-<->B 


Translation  into  Elf  is  straightforward: 
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doubleneg  :  I-  A  ->  I-  (not  (not  A))  ->  type, 
dbl.neg  :  doubleneg  D  (noti  ([p]  (note  p  D))). 
doubleneg. l.prem  : 

(I-  A  ->  I-  B)  ->  (I-  (not  (not  A))  ->  |~  (not  (not  B)))  ->  type, 
dbl.neg. l.p  : 

doubleneg. l.prem  D  ([pnnA]  (noti  ([pnB]  note  pnnA  (noti  ([pA]  note  pnB  (D  pA)))))). 

We  use  these  double  negation  transformations  in  tail- recursion  introduction  to  hide  the  unwanted 
computation  of  the  witness  r.  We  change  the  transformation  so  that  it  produces  an  inductive 
subproof  of 

V/ .VA; .  3s . -»-i3r .  $(/,r)  A  '9{k,r,s) 

To  obtain  this  proof  we  apply  the  double  negation  transformation  doubleneg  to  the  part  of  the 
base  case  of  the  induction  that  proves  the  existence  of  r.  Without  the  use  of  double  negation,  the 
base  case  has  the  following  form: 

Proof  schema  4.16 

^(D,ro)  9(k,To,so{k)) 

^([],ro)  A  9{k,ro,so{k)) 

3r.#([],r)  A  r,so(fc)) 

Vfc.3s.3r.#([],r)  A  ^{k,r,s) 

(The  double  horizontal  bar  elides  the  obvious  quantifier  introductions.) 

With  double  negation  it  has  the  form: 

Proof  schema  4.17 

^([]»ro)  ^{k,ro,so{k))  ^ 

_  ^([],ro)  A  ’^(fc,ro,8o(fc)) 

-’3r.#([],r)  A  9{k,r,8Q{k))  •3r.#([],r)  A  r,so(A:)) 


-'-i3r .  $([],r)  A  '9{k,r,Bo{k)) 
Vfc.3s.->-i3r  .^([],r)  A  'i'(fc,r,s) 
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In  a  similar  way  we  apply  the  transformation  doubleneg-l^rem  to  the  portion  of  the  step  case 
that  proves  the  existence  of  r. 

Since  the  recovery  lemma  Xr  requires  ^(1,  r)  as  a  premise,  and  this  premise  is  no  longer  avail¬ 
able,  we  must  also  apply  double  negation  to  this  part  of  the  proof;  the  whole  transformed  proof 
now  has  as  conclusion: 

We  could  again  implement  the  modified  transformation  as  a  simple  rewrite  rule,  but  it  is  more 
convenient  to  retain  separate  judgments  for  introducing  double  negations,  and  introduce  subgo  ds 
into  the  tail-recursion  transformation.  The  Elf  code  fragment  that  builds  the  base  case  of  the 
induction  subproof 

(Iforalli  ([k]  lexistsi  _  (SO  k)  (lexistsi  _  RO  (and!  Db  (I_b  k))))) 


becomes 

(Iforalli  [k]  (lexistsi  _  (SO  k)  (NN_I_b  k))) 


and  we  add  the  following  subgoal  to  construct  the  proof  of  the  double  negation  (which  is  schematic 
in  k)  and  bind  it  to  NN-I_b: 

<“  ({k}  doubleneg  (lexistsi  _  RO  (andi  Db  (I_b  k)))  (NN.I_b  k)) 


In  the  previous  version  of  the  transformation  the  step  case  of  the  induction  is  built  by  the 
following: 

([1]  [p]  [x]  (Iforalli  [k] 

(lexistse  ([s]  [q’] 

(lexistse  ( [r]  [q] 
lexistsi  _  s 
(lexistsi  _  (F  X  r) 

(andi  (Ds  x  1  r  (andel  q))  (I_s  x  k  r  s  (ander  q))))) 
q’)) 

(Iforalle  (H  x  k)  p)))) 


We  change  this  to: 

([1]  Cp]  [x]  Iforalli  [k] 

(lexistse  ( [s]  [h] 
lexistsi  _  s  (NN_I_s  1  x  k  s  h)) 
(Iforalle  (H  x  k)  p))) 


no 


Again  we  need  a  subgoal  to  construct  the  proof  of  the  double  negation,  this  time  schematic  in  the 
parameters  x  . . .  s  and  the  assumption  hyp,  and  bind  it  to  NN-I-s 

<-  ({1}  {x}  {k}  {8} 
doubleneg.  1  .prein 

([h3rp:  I-  (lexists  ([r]  (and  (Phi  1  r)  (Psi  (H  x  k)  r  s))))] 

(lexistse  ([r]  [q:  |-  (and  (Phi  1  r)  (Psi  (H  x  k)  r  s))] 

(lexistsi  _  (F  X  r) 

(andi  (Ds  x  1  r  (andel  q))  (I_s  x  k  r  s  (ander  q))))) 
hyp)) 

(NN_I_s  1  X  k  s)) 


The  previous  version  of  the  transformation  completes  the  proof  via  the  following: 

(Iforalli  ([1] 
lexistse  ([s]  [p*] 

lexistse  ([r]  [p]  (lexistsi  _  s  (I_r  1  r  s  p))) 

P’) 

(Iforalle  KO 
(Iforalle  1 

%%  New  inductive  sub-proof: 


With  double  negation  this  becomes: 

(Iforalli  [1] 

(lexistse  ([s]  [p]  lexistsi  _  s  (NN_I_r  1  s  p)) 
(Iforalle  KO 
(Iforalle  1 

Vh  New  inductive  sub-proof: 


The  following  subgoal  builds  a  proof  of  the  required  double  negation,  schematic  in  1  and  s,  and 
binds  it  to  NN_I  jt 

<-  ({1}  {8} 

doubleneg. l.prem  ([q]  lexistse  ([r]  [q’]  I.r  1  r  s  q’)  q)  (NN.I.r  Is)). 

For  the  select  example  this  transformation  yields  the  following  program; 


Program  4.18 


Ill 


fun  sel  1  = 

let  fun  sel’  nil  *  (fn  k  =>  k) 

I  sel’  (x::l’)  *  let  val  p  =  (sel’  1’)  in 

fn  k  «>  (p  (if  X  >>:  2  then  (x::k)  else  k))  end 
in  (sel’  1  nil) 
end; 


After  the  introduction  of  double  negation  the  transformed  proof  proves  V/ .  3s  .  Thus 

this  is  an  example  of  specification  transformation  as  well  as  proof  transformation.  In  what  sense 
then  does  the  extracted  program  meet  the  original  specification  V/ .  3s .  $(/,s)?  If  the  only  ad¬ 
missible  sense  of  the  phrase  “meets  a  specification”  is  “is  extracted  from  a  constructive  proof  of 
a  specification”,  then  it  does  not.  But  when  $  is  not  informative  (as  in  the  example)  the  term 
extracted  from  a  proof  of  $  has  no  computational  use;  that  is  the  point  of  simplification  during 
extraction.  From  the  point  of  view  of  pure  verification,  ->->$  is  an  equally  good  specification. 
This  loose  argument  is  supported  by  the  fact  that  other  systems  use  closely  related  techniques  to 
suppress  computation.  The  PX  system  [Hay90]  provides  a  modal  operator,  equivalent  to  double 
negation,  for  succinctly  expressing  classical  truth.  Sasaki  [Sas86]  uses  double  negation  in  the  op¬ 
timization  of  Nuprl  programs,  and  also  points  out  that  other  kinds  of  uninformative  formulas  can 
also  be  exploited  to  suppress  computation.  Paulin- Mohring  [PM89]  gives  a  type  in  the  Calculus  of 
Constructions  for  any  A  that  hides  its  informative  contents;  this  type  is  not  quite  the  double  nega¬ 
tion  of  A  but  is  a  simpler  type  with  similar  properties.  Schwichtenberg  [Sch85]  defines  a  classical 
existential  quantifier  equivalent  to  the  double  negation  of  the  constructive  one.  He  shows  that  his 
system  is  closed  under  the  Markov  rule  by  an  analysis  of  normal  derivations  that  is  closely  related 
to  the  double  negation  transformations  we  use. 

Aside  from  these  general  considerations,  although  we  have  not  carried  out  a  proof,  it  is  evident 
that  the  tail-recursion  transformation  with  double  negation  yields  an  extracted  program  that  is 
functionally  equivalent  to  the  transformation  of  Figure  4.5,  if  the  predicate  $  is  not  informative. 
This  follows  from  two  considerations.  First,  extraction/simplification  “ignores”  uninformative  sub¬ 
proofs,  so  the  only  computationally  relevant  expressions  are  those  extracted  from  the  witnessing 
term  for  3s .  $(/,s);  second,  this  witness  is  unaffected  by  the  double  negation  introductions. 


4.4  Discussion 

We  have  shown  how  a  well-known  program  transformation  strategy,  conversion  of  a  recursive  func¬ 
tion  definition  to  tail-recursive  form,  can  be  encoded  and  generalized  as  a  proof  transformation 
expressed  as  a  rewrite  rule. 

This  encoding  provides  two  levels  of  correctness  guarantees.  At  the  program  level,  we  know  that 
the  program  meets  its  specification  because  it  is  extracted  from  a  proof  of  the  specification.  This 
guarantee  is  inherent  in  the  proofs-as-programs  methodology,  independent  of  implementation.  At 
the  level  of  proofs,  the  LF  type  system  ensures  that  the  transformed  proof  is  a  valid  proof  of  a 
particular  known  end-formula.  This  is  the  same  assurance  that  the  object  logic  encoding  gives  for 
inference  rules.  As  Harper  et  al.  point  out  [HHP93],  given  the  kind  of  encoding  of  natural  deduction 
we  have  used,  LF  does  not  distinguish  between  inference  rules  and  proofs  of  higher-order  judgment 
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type.  Similarly,  there  is  no  distinction  between  inference  rules  and  the  proof  transformation  we 
have  demonstrated  here.  It  may  be  viewed  as  a  derived  rule  of  the  logic,  although  one  of  an  unusual 
kind:  we  normally  think  of  an  inference  rule  as  taking  proofs  of  some  premises  Ai  and  giving  a 
proof  of  some  new  formula  A.  But  the  purpose  of  the  proof  transformation  is  to  construct  a  new 
proof  with  a  different  structure,  which  may  have  the  same  end-formula  as  its  input  proof  (as  in  the 
naive  version  of  the  tail-recursion  transformation). 

It  may  seem  that  our  proof  transformation  is  significantly  different  from  a  derived  rule  of  infer¬ 
ence  because  it  analyses  the  structure  of  its  input  proof,  whereas  an  inference  rule  depends  only  on 
the  end-formula(s)  of  its  input  proof(s).  This  difference  is  an  artifact  of  the  way  we  have  formulated 
the  transformation.  It  is  convenient  to  think  of  the  transformation  as  taking  a  proof  matching  Proof 
Schema  4.5  as  input  because  the  writing  of  a  proof  of  that  form  is  an  easy  and  natural  first  step 
in  program  development.  But  we  could  also  conceive  the  transformation  as  the  proof  of  a  rather 
baroque  derived  rule  of  inference; 

- p  - p  - p 

$(/,  r)  A  ®(ko,»*,s)  9{h{x,k),r,s) 

*(D.ro)  «(x  *(/,«)  r), s)  rg, so(l’)) 

V/ .  3s  .  -•-'#(/,  s) 

From  a  formal  point  of  view  the  only  unusual  feature  of  this  rule  is  the  imposition  of  constraints 
on  individual  terms  represented  by  the  occurrences  of  rq  . . .  h. 

The  ability  to  express  the  tail-recursion  transformation  as  the  proof  of  a  derived  rule  of  infer¬ 
ence  is  significant  because  it  results  in  a  static,  declarative,  yet  effective  formulation  that  can  be 
proved  correct  by  the  LF  type  system.  This  kind  of  transformation  can  be  contrasted  with  proof 
transformations  like  cut-elimination  (normalization  in  natural  deduction  systems)  or  the  double¬ 
negation  translations  studied  by  Murthy  [Mur90],  which  correspond  to  inference  rules  that  are  not 
derived,  but  admissible.  The  difference  is  significant  for  both  the  generality  and  the  efficiency  of 
the  transformations.  An  admissible  rule  does  not  remain  valid  under  aU  extensions  of  the  logic 
in  question,  but  a  derived  rule  does.  Thus  a  transformation  expressible  as  a  derived  rule  remains 
applicable  as  we  work  in  different  theories.  Moreover,  an  admissible  rule  is  usually  proved  by  in¬ 
duction  over  the  structure  of  proofs;  as  a  result  the  complexity  of  its  implementation  is  high.  By 
restricting  ourselves  where  possible  to  derived  rules  we  obtain  transformations  that  are  valid  for  any 
theories  we  may  wish  to  add  to  the  core  object  logic,  and  that  are  feasible  to  implement.  On  the 
other  hand  we  may  also  expect  to  be  able  to  do  more  with  an  admissible  rule  that  is  not  derived. 
Murthy’s  translations  from  classical  to  constructive  logic  are  a  notable  example  of  a  complex  and 
correspondingly  powerful  proof  of  admissibility. 


Chapter  5 

Case  Studies 


In  this  chapter  we  turn  from  the  discussion  of  techniques  for  encoding  proof  transformations  to 
the  application  of  these  transformations  to  program  development.  We  develop  two  case  studies: 
breadth-first  search  in  a  tree,  and  depth-first  search  in  a  directed  graph.  These  search  procedures 
have  applications  in  graph  problems  such  as  the  detection  of  cycles,  finding  connected  components, 
and  topological  sort. 

In  our  development  of  breadth-first  search  we  adapt  the  tail-recursion  transformation  of  the 
previous  chapter.  As  in  the  example  of  the  select  program,  the  transformation  again  induces  a 
change  of  functionality  in  the  extracted  program.  In  our  study  of  depth-first  search  we  consider 
how  proof  transformation  can  be  used  to  adapt  to  a  small  change  in  specification:  we  begin  with  a 
program  to  compute  the  transitive  closure  of  a  relation,  and  consider  how  to  adapt  its  proof  when 
the  specification  is  changed  to  reflexive  transitive  closure.  Here  we  develop  a  proof  transformation 
closely  related  to  the  program  transformation  technique  of  finite  differencing  [PK80].  In  both  case 
studies,  we  examine  the  problem  of  removing  function  parameters  that  act  as  “loop  bounds”:  they 
represent  explicit  termination  proofs,  but  serve  no  purpose  for  computation. 


5.1  Breadth-first  search  in  a  tree 


Breadth-first  search  is  a  simple  procedure  often  presented  in  terms  of  a  queue  and  a  while  loop 
that  terminates  when  the  queue  is  empty  [AHU83].  Termination  of  the  loop  is  not  quite  straight¬ 
forward  to  see,  even  in  the  absence  of  the  complications  introduced  by  the  possibility  of  cycles  in 
a  general  graph.  This  section  considers  the  simplest  possible  case,  that  of  a  tree.  We  begin  with 
a  straightforward  proof  by  induction  on  a  measure  of  the  size  of  the  tree,  which  yields  a  function 
defined  by  primitive  recursion  over  natural  numbers.  The  recursion  parameter  is  superfluous  for 
the  computation,  so  the  next  step  in  the  development  is  to  change  the  basis  of  the  induction  in 
order  to  remove  this  parameter.  Finally,  we  transform  the  proof  to  tail-inductive  form  to  obtain  a 
function  definition  that  can  be  compiled  to  the  standard  while-loop  form  of  the  algorithm. 
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5.1.1  Definitions 

The  usual  theories  of  lists  and  natural  numbers  are  assumed  as  a  basis  for  the  example.  The  syntax 
for  lists  given  in  Chapter  4  is  extended  by  adding  a  definition  of  an  append  function  for  lists, 
denoted  by  o. 

Definition  5.1  (Labelled  trees,  forests) 

1.  A  labelled  tree  is  a  structure  node(ar,/)  where  x  (the  label)  is  a  natural  number  and  I  is  a  list 
of  labelled  trees. 

2.  A  forest  is  a  list  of  labelled  trees. 


Definition  5.2  x  £t  t  (^  labels  a  node  oft)  if 

1.  t  —  node(x,/),  or 

2.  t  =  node(t/,/),  x  ^  y,  and  there  is  a  tree  u  in  I  such  that  x  Gt  u. 

We  extend  the  notation  to  forests  in  the  obvious  way;  x  I  if  there  is  a  tree  u  in  I  such  that  x  €«  u. 


A  structural  induction  principle 
rule,  parametric  in  x  and  1: 


for  labelled  trees  can  be  expressed  by  the  following  inference 

- P 

Vti.tt  €  /  D  [ult]A 


[node(x,/)/t]A 
'it.  A 


INDt'’ 


Definition  5.3  The  size  of  a  tree  is  size(node(x,/))  =  1  +  '£t^isize{t). 
Again,  we  extend  the  notation  to  forests:  size(/)  =  I^tejsize(t). 


5.1.2  An  initial  algorithm 

The  traversal  problem  can  be  specified  as  one  of  collecting  all  the  labels  of  a  given  tree. 
Specification  5.4 

'it  .3r  .'iy  .y  £  r  ^  y  £t  t 

The  method  of  proof  determines  the  order  of  traversal.  A  proof  by  structural  induction  on  trees 
leads  to  a  depth-first  traversal.  For  a  breadth-first  traversal  we  use  induction  on  the  size  of  a  list 
of  trees.  Here  is  a  sketch  of  an  initial  proof.  (Recall  that  o  denotes  the  append  function.) 


Proof  5.5  We  first  generalize  to  a  forest  /  and  prove 
Lemma  5.6  in.il .  size(/)  =  n  D  {3r  .iy .  y  £  r  y  0 
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by  induction  on  n.  If  n  =  0,  /  must  be  the  empty  list,  so  choose  r  =  [].  Otherwise  n  >  0,  and 
I  =  node(a:,  v)  ::  u  for  some  a:,  v,  and  u.  Since  size(uoi;)  =  n  -  1,  by  the  induction  hypothesis  there 
is  a  list  r'  such  that  Vy .  y  G  r'  o  y  «  o  u.  Then  x  ::  r'  satisfies  Vy .  y  6  x  ::  r'  y  Gt  /.  □ 

Formalizing  the  proof  and  extracting  a  program  requires  adding  a  tree  datatype  with  its  size 
function  to  the  object  logic  and  programming  language.  We  give  an  ML  version  of  the  necessary 
primitives: 

datatype  *’a  tree  *  node  of  (**a  *  (*'a  tree)  list) 
fim  size  (node(x,l))  = 

1  +  (fold  (fn  (a,b)  =>  a+b)  (map  (fn  a  =>  size  a)  1)  0) 


Then  the  following  can  be  extracted  from  the  proof: 

Program  5.7 
fim  bfs  t  - 

let  fun  bfs.aux  0  []  =  □ 

I  bfs.aux  0  (t::l)  =  (any  (neg  ())) 

I  bfs.aux  n  □  =  (any  (neg  ())) 

I  bfs.aux  n  ((node  (x,v))::u)  =  (x:: (bfs.aux  (n-1)  (uCv))) 
in  (bfs.aux  (size  t)  [t])  end 


Recall  that  program  extraction  produces  (any  (neg  ()))  from  the  inference  1  1-  C  where  C  is 
arbitrary.  This  occurs  in  Proof  5.5  when  the  precondition  size(/)  =  n  is  false. 

5.1.3  Transforming  the  domain  of  induction 

Because  of  the  use  of  induction  on  natural  numbers,  Program  5.7  heis  an  extraneous  parameter  n. 
This  corresponds  to  a  termination  proof  for  the  search.  The  parameter  n  can  be  eliminated  after 
program  extraction  using  Sasaki’s  dead  code  unification  technique  [Sas86].  Another  approach  is 
described  for  PX  in  [Hay90];  this  can  be  adapted  in  an  ad-hoc  way  to  our  setting.  The  advantage 
of  this  approach  is  that  it  operates  at  the  level  of  proofs  and  simplifies  further  proof  transformation. 

PX  provides  conditional  inductive  generations  to  support  the  definition  of  inductively  defined 
sets  and  the  generation  of  inference  rules  for  induction  over  these  sets.  The  simple  formalism 
presented  here  does  not  support  this  kind  of  definition,  but  at  the  meta-level  one  can  introduce  a 
new  induction  principle  and  prove  that  it  is  a  derived  rule  by  giving  a  transformation  that  expands 
an  application  of  the  new  rule  to  a  proof  using  only  more  primitive  rules.  The  type-checking 
of  an  Elf  encoding  of  the  transformation  corresponds  to  checking  the  derivation  of  the  induction 
rule.  Specifying  how  to  extract  code  from  the  new  inference  rule  also  allows  the  transformation 
to  be  applied  (in  the  other  direction)  to  Proof  5.5  in  order  to  obtain  better  extracted  code.  As 
Hayashi  points  out,  this  technique  allows  the  separation  of  the  termination  proof  of  a  program  from 
other  verification  considerations;  the  derivation  corresponds  to  the  termination  proof  of  a  program 
development  in  the  PX  style. 
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The  new  induction  principle  needed,  tree  list  induction,  can  be  formulated  as  follows; 

7 - P 

[u  o  w//]j4 


I  D/^]^  [node{x,  v) ::  u/l]A 

vTa 


INDts'’ 


The  derivation  of  the  rule  follows  from 

1.  V/  :  tree  list  .3n.Ti  =  size(/)  is  provable  by  list  induction  with  a  nested  structural  induction 
on  trees. 

2.  Vn  :  nat .  V/  :  tree  list .  n  =  size(/)  D  A  is  provable  by  induction  on  natural  numbers  from  the 
premises  of  INDts  and  the  definition  of  size. 

3.  From  (1)  and  (2)  V/ :  tree  list .  A  follows  trivially. 

Using  this  derivation  as  a  transformation  on  Proof  5.5  gives  the  following  proof  of  Specifica¬ 
tion  5.4: 

Proof  5.8  We  generalize  to  a  forest  I  and  prove 
Lemma  5.9  V/ .  3r .  Vj/ .  y  €  r  o  y  €f  / 

by  induction  on  size(/).  When  I  is  the  empty  list  we  choose  r  =  [].  Otherwise  write  I  as  node(i,  v)  :: 
u.  By  the  induction  hypothesis  there  is  a  list  /  such  that  'iy  .y  £  r'  ^  y  °  v.  Then 

'iy  .y  e  X  ::  r'  y  et  I-  ^ 

Code  extraction  for  the  new  induction  principle  can  be  specified  in  the  same  style  used  for  the 
core  object  logic  in  Section  2.3.2.  We  depart  from  that  presentation  by  giving  the  extracted  code 
in  ML  syntax,  generating  a  function  definition  where  /  is  a  fresh  variable  name. 


XSiNDxs 


Then  the  following  program  can  be  extracted  from  Proof  5.8: 
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Program  5.10 
fun  bfs  t  * 

let  fun  bfs.aux  □  *  □ 

I  bfs.aux  ((node  (x,v))::u)  =  (x:: (bfs.aux  (ufiv))) 
in  (bfs.aux  Ct])  end 


5.1.4  Adapting  the  tail-recursion  transformation 

Using  the  fold- unfold  system  Program  5.10  can  be  transformed  to  a  tail-recursive  definition  by 
the  same  method  shown  in  section  4.1.2  for  the  select  example.  Just  as  in  that  derivation,  the 
resulting  program  accumulates  its  partial  result  by  applying  the  append  function.  To  obtain  a 
tail-recursive  program  via  proof  transformation,  we  adapt  the  tail  recursion  transformation  to  tree 
list  induction,  and  apply  it  to  Proof  5.8. 

In  order  to  formulate  proof  transformations  for  a  class  of  inductive  proofs,  it  is  useful  to  introduce 
some  definitions.  These  are  rather  weak  definitions,  as  it  is  not  our  purpose  to  formally  treat 
induction  in  general  in  our  simple  implementation,  but  only  to  give  an  informal  generalization 
which  can  easily  be  formalized  for  a  given  induction  rule.  An  induction  principle  that  meets 
Definition  5.11  is  not  thereby  a  valid  one;  it  must  be  proved  correct  using  the  method  of  the 
previous  section. 

Definition  5.11  A  simple  induction  principle  o/the  ohjeci  logic  is  an  inference  rule  of  the  form 

'Pi  ■"'Pm 

- INDs^ 

Vxi .  . .  .Vx„  .PdA 

The  precondition  P  may  be  empty,  but  must  be  Harrop  if  it  is  nonempty.  Each  premise  Vi  has  the 
form: 

1.  [tin  •  •  •  . . .  ,Xn]A  with  each  tij  either  a  constant  term  or  the  parameter  Xj,  or 

2. 

—  p  - p  - —p 

Ci\  ...  Cik  •  •  •  9  1  ■  9  ^n]-^ 

[til » •  •  •  >  tin/Xl,  •  •  • ,  Xn]A 

That  is,  Vi  may  depend  on  the  premises  Cij  and  [dii,. . . ,di„/xi,. . .  ,in]A  discharged  by  the 
application  of  the  rule  iNDs .  Each  Cij  is  atomic. 

Given  such  an  induction  principle, 

1.  A  is  the  induction  predicate. 

2.  P  is  the  precondition 
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S.  Xi  ...Xn  are  the  parameters  of  induction. 

4-  A  premise  of  the  form  (1)  above  is  a  base  case. 

5.  A  premise  of  the  form  (2)  above  is  an  inductive  case. 

6.  For  an  inductive  case  Vi  the  terms  are  the  descent  terms. 

7.  For  an  inductive  case  Vi  any  parameters  occurring  in  Cn  . .  .Cik,  dn,. . .  ,din,  or  tn,...,  tin 
are  the  proper  parameters  of  Vi. 

For  example,  in  tree  list  induction  inDts  ,  xi . . .  x„  corresponds  to  the  single  variable  /  of  type 
tree  list.  The  precondition  is  empty.  The  base  case  Pi  is  [  [j//]i4.  The  inductive  case  Pi  is 
[node(*,t;)  ::  u//]i4,  with  a  single  discharged  assumption  { [u  o  t;//].4},  and  proper  parameters 
x,u,v. 

Given  a  simple  induction  principle,  a  tail  recursion  transformation  can  be  written  for  it.  We 
describe  it  in  terms  of  higher-order  patterns  using  the  notation  of  Section  4.1.3.  The  transformation 
is  defined  on  an  input  proof  that  terminates  in  an  application  of  the  given  induction  rule  with 
an  induction  predicate  of  the  form  3r.$(xi,...,x„,r),  where  xi,...,x„  are  the  parameters  of 
induction.  Each  base  case  Pi  has  the  following  form,  where  xj, . . . ,  x„  may  occur  free  in  t,i , . . . , t,„ 
(compare  Proof  schema  4.5): 

Proof  schema  5.12 

^(^il  >  •  •  •  5  tin,  ^i) 

- 31 

3r  .  ^(tii, ...  ,tin,  r) 

Each  inductive  case  Vi  has  the  following  form,  where  the  proper  parameters  Pii, . . .  ,p,j  of  Vi  may 
occur  free  in  Cii . . .  Cj*,  dji, . . .  ,din,  and  t^, . . .  ,ti„: 

Proof  schema  5.13 

-  -  - 9i 

Cii  ...  Ci^  ^(dii , . . . , din, r) 

77i 

^(til,  •  •  • ,  tin,  f«(Pil,  •  •  •  ^)) 

- 31 

3r.4^(dii  , . . .  ,din,  r )  3t*  .  ^(tii , « .  •  ,  tin , 

- - - ; - 3E’' 

3r  .  ^(tii , . . , ,  tin,  ^ ) 

As  in  the  special  case  of  Chapter  4  the  transformation  requires  an  auxiliary  specification  'i' 
expressing  the  way  in  which  the  result  is  to  be  accumulated.  Thus  the  transformed  proof  contains 
a  subproof,  terminating  in  an  application  of  the  given  induction  rule,  of 

Vxi .  ...Vxn.P  D  VA:.3s.3r.^(xi,...,Xn,r)  A  9(k,r,s) 
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For  ease  of  comparison  the  lemmas  needed  for  the  transformation  are  given  here  in  the  style  of 
Section  4.1.3,  although  in  an  implementation  the  lifted  forms  described  in  Section  4.2  are  easier  to 
work  with. 

1.  The  tramsformation  requires  a  proof  of 
Lemma  schema  5.14  (Recovery  lemma) 

Vari .  ...Vin  .Vr.Vs.(^(ii,. r)  A  'J'(ko,  r,s))  D 
for  some  term  ko. 

2.  For  each  inductive  case  Vi  of  the  subproof,  the  transformation  requires  a  proof  2i  of 
Lemma  schema  S.IS  (Inductive  case  lemma) 

Vpii - Vp,jV*: .  Vr .  Vs .  ’J'(h(p.i , . . . , pi_, ,  fc),  r,  s)  D  f j(p,i , . . . ,  p,y ,  r ),  s) . 

where  the  pattern  f,(pa,. . .  ,p,j,r)  is  given  by  the  original  proof  and  the  pattern  h(p,i, . .  .,Pij,k) 
is  supplied  by  the  user. 

3.  For  each  base  case  we  require  a  proof  Xi  of 
Lemma  schema  5.16  (Base  case  lemma) 

Wk.9{k,TiMk)) 

r,  is  the  witness  term  for  the  base  case  of  the  original  proof;  s^  is  supplied  by  the  user. 

The  construction  of  the  result  of  the  transformation  is  analogous  to  the  special  case  described 
in  Chapter  4.  For  each  base  case  of  the  input  proof  the  transformation  constructs  the  following 
subproof  from  the  original  proof  and  the  corresponding  base  case  lemma.  Here  X\  is  derived  from 
Xi  by  VE  (it  corresponds  to  the  lifted  form  of  Section  4.2).  Double  horizontal  lines  indicate  the 
obvious  sequence  of  introduction  rules. 

Proof  schema  5.17 


^(t.i  9  •  •  •  1  )  'i'(fc,r.,s,(*:)) 

9  •  •  •  9  ^1919  Ti)  A  «'(!:,  r„Si(fc)) 

VA;.3s.3r.$(t,i,...,t,„,r)  A  'Jf(A:,r,s) 


Similarly,  for  each  inductive  case  2>,-  the  following  subproof  can  be  constructed  from  the  original 
proof  and  the  corresponding  inductive  case  lemma.  Again  X^  corresponds  to  the  lifted  form  of  the 
proof  X,  of  Lemma  Schema  5.15,  and  double  lines  indicate  obvious  introductions  and  eliminations. 
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Proof  schema  5.18 


Cij  ...  Ciic  ^(dti , . . . ,  din,  r)  ^(d,i, . . . ,  d,n,  r)  A  'JE'(h(p,i, . . .  ,pij,fc),r,  s) 


Vi 


Ti 


♦(til  » •  •  •  5  Ijrn 


ft(Pil»  •  •  •  yPiji  ^)» 


Al 


*(t.l  » •  •  •  »li»n  ^i(Pilt  •  •  •  *Pf.j*  *’))  ^  '®^(^>^i(P«li  ■  ■  ■  »P«j»  ^)j5) 
Vfc.3s.3r.^(t,i,...,t,„,r)  A  «'(*:, r,s) 


From  these  subproofs  the  transformation  builds  an  induction  in  the  obvious  way.  The  original 
conclusion  then  follows  from  the  recovery  lemma  Vr  (again  V'r  denotes  the  lifted  form): 

Proof  schema  5.19 


V*iND 

Vxi .  ...Vx„.P  D  Vfc.3s.3r.^(xi,...,Xri,r)  A  r,s) 

^(xi,...,xn,r)  A  'i'(ko,r,s) 

Vr 

^(®l> • •  •  » 

Vxi - Vx„.P  D  3s.#(xi,...,Xn,s) 

Except  for  the  difference  in  the  induction  principle,  the  transformation  can  be  applied  to  the 
breadth-first  search  problem  in  the  same  way  as  it  was  to  the  list  select  example;  the  same  auxiliary 
specification  ^{k,  x,  r)  =  Vy .  y  €  r  (p  €  a:  V  y  G  fe)  can  be  used. 

The  new  specification  for  the  inductive  subproof  is: 

Specification  5.20 

V/ .  Vfc .  3s .  3r .  (Vy .  y  6  r  o  y  €«  /)  A  (Vy  .yGs^(yer  V  yGfc)) 

We  show  only  the  instantiation  of  the  crucial  lemma  schema  5.15  that  establishes  the  induction 
step.  The  term  h2{x, u,v,k)  that  governs  the  accumulation  of  the  partial  result  is  x  ::  k,  and 
the  term  f2(x,u,u,r)  given  by  the  original  inductive  subproof  is  x  ::  r.  Thus  the  instantiation  is 
(omitting  the  unused  parameters  u  and  v): 

Lemma  5.21 

Vx  .Vfc .  Vr . Vs . [Vy  .y  G  s  (y  G  r  V  y  G  x  ::  fc)]  D  [Vy  .y  G  s  (y  G  x  ::  r  V  y  G  fc)] 
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Inserting  the  appropriate  instantiations  of  the  lemma  schemas  5.14,  5.15,  and  5.16  into  the 
inductive  subproof  of  Proof  5.8,  results  in  a  new  proof  of  Specification  5.4.  We  sketch  the  proof 
here: 

Proof  5.22  We  first  prove 

V/ . VA: . 3s . 3r . (Vy .y  £  r  y  et  1)  A  (Vy  .y  e  s  ^  (y  e  r  V  y  €  A:)) 

by  induction  on  the  tree  list  /.  If  /  =  []  choose  r  =  (]  and  s  =  k.  Otherwise  /  =  node(a:,  u)  ::  v.  By 
the  induction  hypothesis  there  are  lists  s'  and  r'  such  that  Vy .  y  €  s'  4^  (y  €  r'  V  y  £  x  ::  k)  and 
Vy .  y  €  r'  O  y  €t  w  o  u.  Then  let  s  be  s'  and  let  r  be  a;  ::  r'. 

Then  for  any  tree  t  there  are  lists  s  and  r  such  that  (Vy  .y  £  r  ^  y  [t])  A  (Vy . y  €  s  o  (y  € 
r  V  y  6  [])).  Then  s  contains  exactly  the  labels  of  1.  □ 

As  in  the  example  of  Chapter  4,  it  is  necessary  to  transform  the  proof  further  by  inserting  a 
double  negation  in  order  to  eliminate  the  computation  of  r.  The  following  program  can  then  be 
extracted: 

fun  bfs  t  = 

let  fun  bfs.aux  □  k  =  k 

I  bfs.aux  ((node  (x,v))::u)  k  =  (bfs.aux  (u#v)  (x::k)) 
in  (bfs.aux  [t]  □)  end 


5.1.5  Formalization 

The  formalization  of  tail- recursion  introduction  in  Elf  for  a  given  induction  principle  is  straightfor¬ 
ward,  following  the  procedure  described  in  Chapter  4.  Formalizing  the  transformation  in  general  is 
more  difficult  and  is  beyond  the  scope  of  this  thesis,  requiring  a  general  treatment  of  (restricted)  in¬ 
duction.  Ideally,  the  system  would  be  augmented  with  a  way  of  introducing  an  inductive  definition 
(e.g.,  as  in  Nuprl,  Coq  or  PX)  with  an  associated  rule  of  inference.  An  Elf  logic  program  could  then 
be  written  to  analyze  any  proof  by  induction  and  apply  the  appropriate  form  of  transformation. 

Figure  5.1  shows  the  formalization  of  the  syntax  of  trees  and  tree  lists,  with  the  functions  append 
and  size,  equality  for  tree  lists,  and  quantifiers. 

The  change  of  induction  principle  of  Section  5.1.3  is  formalized  by  giving  a  derivation  in  Elf  of 
the  induction  principle  inDts-  The  first  step  is  to  formulate  inDts  as  an  inference  rule: 

indts  :  {A:  tlist  ->  o} 

I-  (A  nl) 

->  ({X:i}  •CU:tlist}  {V:tlist} 

I-  (A  (appnd  U  V))  ->  |-  (A  (cns  (nod  X  V)  U))) 

->  I  -  (If orall  A) . 


Then  a  pattern-driven  proof  transformation  can  be  written  to  convert  any  proof  using  inDts  to 
one  using  induction  on  natural  numbers,  lists  of  trees,  and  trees,  or  vice-versa.  Type-checking  the 
clause  defining  the  transformation  verifies  the  derivation  of  the  inDts  inference  rule. 
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tre  :  type, 
tlist  :  t3rpe> 

nod  :  i  ->  tlist  ->  tre. 

nl  :  tlist. 

cns  :  tre  ->  tlist  ->  tlist. 

appnd  :  tlist  ->  tlist  ->  tlist. 

size  :  tre  ->  i. 
tlsize  :  tlist  ->  i. 

leq  :  tlist  ->  tlist  ->  o. 

tforadl  :  (tre  ->  o)  ->  o. 
texists  :  (tre  ->  o)  ->  o. 

lfor2J.l  :  (tlist  ->  o)  ->  o. 
lexists  :  (tlist  ->  o)  ->  o. 


^labelled  trees 
Xlists  of  trees 

Xtree  constructor 

Xempty  tree  list 
Xcons  for  tree  lists 

Xappend 

Xsize  of  a  tree 
Xsize  of  a  tree  list 

Xequality  for  tree  lists 

Xquantif ication  over  trees 

Xquantif ication  over  tree  lists 


Figure  5.1:  Elf  encoding  of  trees  and  tree  lists 
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As  usual  the  transformation  is  encoded  as  a  judgment  and  a  single  defining  clause  that  expresses 
the  rewrite.  The  judgment  is: 

expand.indts  :  {A:  tlist  ->  o}  |-  (Iforall  A)  ->  |-  (Iforall  A)  ->  type. 


For  readability  we  present  the  transformation  in  terms  of  the  following  constants  defining  lemmas 
needed  for  the  derivation.  This  encoding  hides  the  inductions  on  trees  and  lists  of  trees. 

1.  p_nl  :  {L}  I-  (eq  zero  (tlsize  D)  ->  1-  (leq  nl  L)  ->  type. 


That  is,  for  any  list  of  trees  /  and  proof  that  the  size  of  I  is  zero,  there  is  a  proof  that  I  is  the 
empty  list. 

2.  p_cns  :  {L}  {N}  I-  (eq  (succ  N)  (tlsize  L)) 

->  I-  (exists  [x]  lexists  [u]  lexists  [v] 

(and  (eq  N  (tlsize  (appnd  u  v))) 

(leq  (cns  (nod  x  v)  u)  L)))  ->  type. 

That  is,  for  any  1,  n,  and  proof  that  the  size  of  /  is  n  +  1,  there  is  a  proof  that  /  can  be 
decomposed  as  node(x,u) ::  v  with  size(v  ou)  =  n. 

3.  p_ex  :  {L}  I-  (exists  [n]  eq  n  (tlsize  D)  ->  type. 

That  is,  for  any  list  of  trees  $1$  there  is  a  proof  that  $\siz(l)$  exists. 


These  lemmas  are  referenced  as  subgoals  in  the  same  way  as  is  done  for  the  double  negation 
transformations  of  Section  4.3. 

Figure  5.2  shows  the  Elf  code  for  the  rewrite  rule. 


5.2  Depth-first-search  in  a  directed  graph 

This  section  presents  an  example  of  the  use  of  proof  transformation  to  adapt  to  a  small  change  in 
specification.  After  some  preliminary  definitions  and  lemmas  comes  an  initial  proof  and  program  to 
compute  the  transitive  closure  of  a  relation;  if  the  relation  is  viewed  as  a  directed  graph,  the  program 
corresponds  to  a  depth-first  traversal  of  the  graph.  This  proof  is  improved  by  changing  the  domain  of 
induction  using  the  method  of  Section  5.1.3.  The  resulting  proof  is  adapted  to  compute  the  reflexive 
transitive  closure  by  a  process  closely  related  to  the  finite  differencing  program  transformation. 

5.2.1  An  initial  algorithm 

We  begin  with  some  basic  notations  and  lemmas  for  graphs. 
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exp.indts  : 

■CAitlist  ->  o}  {Base.case :  I  -  (A  nl)} 

{Step.case: ({X:i}  {Urtlist}  {Vitlist} 

I-  (A  (appnd  U  V))  ->  |-  (A  (cns  (nod  X  V)  U)))} 
axpand.indts  A 

(indts  A  Basa.case  Step.case) 

(Iforalli  Cl:tli8t] 
existse 

(Cn:i]  Cp:  |-  (eq  n  (tlsize  1))] 
impliase 

(Iforalle  1  (foralle  n 

(ind  ([n]  Iforall  [1]  implies  (eq  n  (tlsize  1))  (A  1)) 

(Iforalli  [1]  impliesi  [q:  |-  (eq  zero  (tlsize  1))] 

(leq_8ubst_o  ([1]  A  1)  (P.nl  1  q)  Base.case)) 

(CnJ  Cp':  (-  (Iforall  CU  implies  (eq  n  (tlsize  1))  (A  1))] 

(Iforalli  [1]  impliesi  [q:  I-  (eq  (succ  n)  (tlsize  1))] 

(existse  ([x]  [pi]  lexistse  ([u]  [p2]  lexistse  ([v] 

[p3:  I-  (and  (eq  n  (tlsize  (appnd  u  v))) 

(leq  (cns  (nod  x  v)  u)  1))J 
(leq_subst_o  ([1]  A  1) 

(ander  p3) 

(Step.case  x  u  v  (impliese  (Iforalle  (appnd  u  v)  p’)  (andel  p3))))) 
p2)  pi)  (P_cns  1  n  q) )))))) 

P) 

(P_ex  D) 

<-  «!}  {q}  p.nl  1  q  (P.nl  1  q)) 

<-  ({1}  {n}  {q}  p.cns  1  n  q  (P.cns  1  n  q)) 

<-  ({1}  p_ex  1  (P_ex  D). 


Figure  5.2:  Elf  derivation  of  tree  list  induction 
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Definitions  and  lemmas 

Definition  5.23  A  graph  is  a  pair  (  V,E  )  where  V  is  a  finite  enumerated  set  of  nodes  and  E  is 
a  binary  relation  on  V . 

Definition  5.24  Given  a  relation  E  &  V  x  V ,  a  node  x  £  V,  and  a  set  U  C  V ,  we  write 

1.  xEy  when  {x,y)eE 

2.  E(x)  for  {y  (  xEy} 

3.  E{U)  for  U  E{x) 

xeu 


Definition  5.25  Given  a  relation  E  ^  V  xV,  we  define 

1.  E"^ ,  the  transitive  closure  of  E,  by 

(a)  xE'^y  when  xEy, 

(b)  xE'^y  when  for  some  z  xEz  and  zE'^y. 

2.  E*,  the  reflexive  transitive  closure  oi  E,  by 

(a)  xE*x, 

(b)  xE*y  when  for  some  z  xEz  and  zE’y. 


Lemma  5.26  Given  a  relation  EinVxV  and  U  CV,  E*{U)  =  U  \J  E'^{U). 

Definition  5.27  Given  a  graph  {V,E  ),  and  nodes  u,v  £V ,  a  path  in  {V,E)  from  u  to  v  is  a 
sequence  (  xo,ii,...,Xn  )  €  V  and  x,\Ex,+i  for  1  <  i  <  n,  and  xq  =  u,  x„  =  v. 

The  length  of  the  path  is  the  number  of  edges  n. 

The  following  definition  models  a  common  explanation  (e.g.  [AHU83])  of  depth-first  search,  in 
which  each  node  is  marked  “seen”  as  it  is  visited,  and  is  thereafter  excluded  from  the  search  in 
order  to  ensure  termination.  This  can  be  modelled  by  restricting  the  codomain  of  the  edge  relation 
E  to  a,  given  subset  U  of  the  node  set  V.  Intuitively,  this  “cuts”  edges  into  the  set  V  \  U  but  not 
the  edges  leaving  the  set.  Operationally,  U  is  the  set  of  unmarked  nodes. 

Definition  5.28  Given  a  binary  relation  E  qV  xV,  and  U  CV,  Eu  =  E  D  {V  x  U).  Ey  denotes 
(Eu)'*',  and  similarly  for  Ey. 

Lemma  5.29  Given  a  graph  {V,E),  sets  R,U  C  U'  C  U,  and  nodes  x,y  e  V ,  u  G  U: 

1.  ^.{R)  C  i+(i?)  and  Ef^,{R)  C  ^(iZ). 

2.  a;(.E{/\{u})*J/  if  and  only  if  there  is  a  path  p  from  x  to  y  such  that  if  u  occurs  in  p  then  u  =  x. 
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3.  x{Eir\{u))^ y  •/  '/  there  is  a  path  p  of  length  n  >  0  from  x  to  y  such  that  if  n  occurs 

in  p  then  u  =  x. 

The  following  lemma  is  crucial  to  depth-first  search  since  the  algorithm  depends  on  tlie  elimi¬ 
nation  of  cycles  for  termination. 

Lemma  5.30  (Cycle  Lemma)  Given  a  graph  {  V,E  ),  a  set  U  C  V,  nodes  x,y  6  V.  and  u  €  U ,  if 
x{Eit)'‘y  then  or  there  is  a  node  z  such  that  and  zEv  and  »( /i.V\{ « ) )*1/- 

Proof  5.31  Assume  «  G  U  and  xEljy.  Then  there  is  a  path  p  =  (  xq,.  . .  ,x„  )  with  n  >  0,  j-q  =  x, 
Xn  =  y>  Xi  G  U  for  i  >  0,  and  for  0  <  i  <  n.  If  u  docs  not  occur  in  p  then 

trivially.  Otherwise  let  xj  be  the  first  occurrence  of  «  in  p  and  let  x^  be  the  last  occurrence  of  ti  in 
P- 

If  j  =  0  (i.e.  u  =  X  =  xo)  then  (  u,xt  -I-  1,. . .  ,i„  )  is  a  path  from  x  to  y;  thus  x{Eii\^  u 
Otherwise  if  j  =  n  (i.e.  ii  =  y  =  x„)  then  (  xo,. . .  ,Xj_i, «  )  is  a  path  from  x  to  y.  Then 
Xj^iEu,  and  H(£(;\{„})*y. 

Otherwise,  (  xo, . . .  ,Xj_i,  «,Xfc+i, . . .  ,x„  )  is  a  path  from  x  to  y.  Then  x(£f?\{„  ))*Xj_i,  Xj_i  Eu. 
and  u{Eir\{u})’y- 

Cotollary:  For  x,y  G  V'  and  u  G  f if  x{Eir)'^y  then  x(£’(?\{ u))'*'y  or  there  is  a  node  r  such  that 
^{Eu\{u))'^~  and  zEu  and  «(£^r\{u})*J/-  ° 

A  proof  and  program  for  transitive  closure 

Depth-first  search  in  a  directed  graph  arises  from  induction  on  a  pair  of  sets  of  nodes  {  IK  It  ).  V 
is  the  set  of  nodes  to  be  searched  and  i?  is  a  set  of  root  nodes  from  which  the  search  begins. 

Here  is  a  specification  for  computing  the  set  of  nodes  reachable  along  a  nonempty  path  from  a 
given  set  of  nodes  ^  in  a  directed  graph  (  V',  E  ): 

Specification  5.32  V(  V',  E  )  :  graph,  R.  RCV  0  31T  .  IT  =  E^{R) 

The  proof  proceeds  by  generalization  to  subsets  U  of  V'  and  to  the  relation  Eir. 

Lemma  5.33  V(  V,E):  graph, U,  R.U,R  C  V  3  311' .  W  =  Ei, { R) 

Specification  5.32  follows  easily  with  U  =  V. 

Proof  5.34  (of  Lemma  5.33)  The  proof  is  by  induction  on  the  pair  of  sets  (  IK  R  ).  .\t  each  step 
of  the  induction  we  decrease  U  or  hold  U  constant  and  decrease  R. 

Case  U  =  {}  or  R  =  {};  then  let  W  =  {}. 

Case  U  /  {}  and  R  —  r  ^  RK  There  are  two  cases: 

1.  Ev(r)  =  {}.  Then  apply  the  induction  hypothesis  to  IKR'  to  obtain  ll  '  =  F^,(R'). 

Claim:  IV'  =  E^i[R).  Write  IV  for  Eir{R).  By  Lemma  5.29  IV'  C  IV.  Suppose  x  G  11;  then 
for  some  r'  G  R,  r'(Eir)'*'x.  If  r'  G  R'  then  trivially  B'lt  cannot  be  r.  for  then 

there  would  be  a  node  u  in  U  with  rEu,  contradicting  Eufr)  =  {}.  So  IV  C  IV'. 
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2.  Eu{r)  =  5  li)  5.  Write  (/'  for  t/  \  {  6  }  and  apply  the  induction  hypothesis  to  U',R  U  {  s  }  to 
obtain  W  =  Ey,(R  U  {s}). 

Claim;  {5}  U  W  =  Ey{R).  Again  write  W  for  Ey{R).  Suppose  x  ^W,  that  is,  r'E^x  for 
some  r'  G  R-  By  the  corollary  to  Lemma  5.30  there  are  two  cases: 

(a)  r'{Eu>)^x.  Then  x  G  W  since  r'  G  iZ  U  {s}. 

(b)  There  is  a  node  z  such  that  r'{Eu>)^z  and  zEs  and  s{Eui)''x.  Ifx  =  s  then  x  G  {  s  }  U  W 
trivially.  Otherwise  s{E(ji)'^x  and  since  sG^U  {s},  iG  W. 

So  W  C  s  U  W'. 

For  the  other  direction  of  set  inclusion,  suppose  x  G  W\  that  is  r'(£j//)'^x  for  some  r'  G 
^U{s}.  Ifr'Gfi  the  inclusion  follows  easily.  If  r'  =  s  then  since  rEs  and  s  £  U  it  follows 
that  r(F(/)+x,  so  x  G  W.  So  W  C  W.  Clearly  s  G  W  since  rEs  and  s  £  U. 


The  proof  is  formalized  as  a  proof  by  nested  induction  on  the  size  of  the  set  U  and  the  structure 
of  the  set  R. 

In  order  to  formalize  the  proof  and  extract  a  program  it  is  necessary  to  extend  the  object 
logic  and  programming  language  with  a  sort  of  Unite  enumerated  sets  with  a  structural  induction 
principle,  and  the  operations  of  disjoint  union  with  a  singleton,  the  deletion  of  a  single  element, 
intersection,  and  cardinality.  On  this  sort  is  built  another  for  graphs.  A  graph  is  represented  a.s 
a  pair  of  a  set  of  nodes  and  a  finite  mapping  that  takes  a  node  to  the  set  of  adjacent  nodes.  The 
object  logic  under  consideration  forces  a  fixed  choice  of  data  type  for  representing  nodes  but  this 
does  not  affect  the  transformation  process.  Note  that  there  are  no  set  comprehensions  in  the  formal 
language;  the  notations  used  in  the  foregoing  definitions  should  be  considered  as  abbreviations. 

Programs  using  these  data  types  are  presented  in  an  ML-like  syntax  extended  as  follows: 

e  ::=  ...  |  empty  |  ei++e2  |  Finite  sets:  empty  set,  singleton  union 

eille2  I  ei&fte2  |  ei — e^  \  crde  |  Union,  intersection,  deletion,  cardinality 
graph(ei,e2)  |  mappCei.eo)  |  Graphs 

The  constructor  ++  is  analogous  to  cons  for  lists;  an  expression  of  the  form  e_l  ++  e_2  constructs 
the  union  of  a  singleton  containing  the  element  o_l  with  a  set  e_2.  The  expression  e_l  —  e_2 
denotes  the  set  obtained  by  deleting  the  element  e_2  from  the  set  e_l.  The  union  and  intersection 
of  two  sets  are  represented  by  1 1  and  M  respectively.  The  size  of  a  set  e  is  obtained  by  crd  e. 

An  expression  graph (V,E)  constructs  a  representation  of  a  graph  (  V,E  );  an  expression 
mapp(x,G)  evaluates  to  the  set  of  nodes  adjacent  to  the  node  x;  that  is,  it  represents  the  com¬ 
putation  of  E{x)  for  a  graph  G  =  {  V,E  ).  As  usual  we  freely  introduce  bindings  to  improve 
readability  of  programs. 

The  argument  and  call  structure  of  the  extracted  program  is  a  consequence  of  the  structure  of 
the  formalization  of  Proof  5.34.  Here  is  a  sketch  of  that  structure: 

First  Lemma  5.33  is  formalized  as 
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Lemma  5.35 

\/{V,E).^n.W.iUCV  A  n  =  \U\)D\/R.RCV  D^W.'^y.yeW  ^  3x.xe  R  A  xE^y 

This  presentation  still  takes  some  liberty  with  notation:  the  use  of  destructuring  is  not  supported 
in  the  object  logical  language.  However  for  readability  we  write  {V,E),V,  and  E  rather  than  G, 
fst(G),  and  snd(G). 

Proof  outline  5.36  The  proof  is  by  induction  on  n.  If  n  =  0  then  !/  =  {};  let  IT  =  {}. 

If  n  =  n'  +  1  then  U  is  nonempty,  and  we  show 

yR.U,RCV  D  3W.\^y.yeW  ^  3x.x  eR  A  xE^y 

by  induction  on  the  structure  of  R.  If  iZ  =  {}  then  let  W  =  {}. 

Otherwise  R  =  r  R'.  There  are  two  cases: 

1.  Eu{r)  =  {}.  Then  apply  the  inner  induction  hypothesis  to  R!  to  obtain  W  and  let  W  =  W. 

2.  Eu{t)  =  s  W  5.  Write  U'  for  f/  \  {s}  and  apply  the  outer  induction  hypothesis  to  U'. 
Instantiate  R  as  R  U  {s}to  obtain  W',  and  let  W  =  { s }  U  W. 


□ 


The  extracted  program: 

Program  5.37 

fun  tclos  (G  as  (graph(V,_)))  R  = 
let  fim  tclos. 1  0  empty  R  -  empty 

I  tclos. 1  0  (u  ++  U)  R  =  raise  neg 
I  tclos. 1  n  U  R  * 
let  fun  tclos. 2  empty  =  empty 

I  tclos.2  (R  as  (r  ++  R’))  = 
case  (mappCr,  G)  ftft  U)  of 
empty  =>  (tclos.2  R’) 

I  (s  ++  S)  *> 

(s  ++  (tclos. 1  (n-1)  (U  —  s)  (s  ++  R))) 
in  (tclos.2  R)  end 
in  (tclos. 1  (crd  V)  V  R)  end 


Although  the  asymptotic  complexity  of  this  program  is  already  good  (jVp,  assuming  appropriate 
implementations  of  the  set  operations),  just  as  in  the  breadth-first  search  program  (Program  5.7), 
the  induction  on  natural  numbers  results  in  an  unwanted  parameter  for  the  function  tclos.l. 
The  nested  set  induction  causes  the  extraction  of  nested  mutually  recursive  function  definitions 
which  can  be  combined  into  one  definition.  The  next  section  shows  how  to  apply  the  technique  of 
Section  5.1.3  to  solve  both  these  problems. 
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E(r)  nU  =  {},A  E(r)  nU  =  s  HI  S,[U\{s}/l7]lrltlRU  {*}//?]>! 


[{}IU]A  [{}IR\A  [THiRlR]A 


[r  W  RIR]A 


'i(,V,E)  .W  .'iR.iU  CV  A  RCV)dA 


Figure  5.3:  Induction  principle  for  depth-first  search 

5.2.2  Transforming  the  domain  of  induction 

The  technique  applied  here  is  the  same  as  that  applied  to  the  breadth-first  search  problem:  intro¬ 
duce  a  new  induction  rule  and  give  its  derivation  from  more  primitive  inference  rules;  encoded  in 
Elf,  the  derivation  can  be  executed  as  a  prograjtn  transformation.  However,  here  the  new  rule  inDdf 
is  more  complex.  It  is  shown  in  Figure  5.3.  We  sketch  its  derivation: 


Theorem  5.38  Given  a  predicate  A  in  which  variables  V,E,U,R  may  occur  free,  the  rule  inDdf 
is  derivable  in  the  object  logic  with  induction  on  natural  numbers  and  structural  induction  on  finite 
sets. 


Proof  5.39  Under  the  given  assumptions,  a  proof  of 

V(  ).Vra.VU.(U  C  y  A  n  =  \U\)D^R.RCV  D  A 

can  be  constructed  by  nested  inductions  on  n  and  the  structure  of  i?  as  in  Proof  outline  5.36. 

Since  the  size  of  a  set  is  primitive  in  the  object  logic,  VI7.3n.n  =  |I7|  is  provable.  The  re¬ 
quired  proof  can  be  constructed  by  the  elimination  rule  for  the  existential  quantifier,  with  trivial 
introductions  and  eliminations  for  implication  and  the  universal  quantifier.  □ 


We  sketch  the  extraction  process  for  the  derived  rule  here  without  giving  all  the  details.  For 
readability  the  extracted  expression  is  shown  in  the  extended  ML-like  syntax  given  above,  using 
recursive  function  definition  and  pattern  matching. 

Given  extraction  assumptions  (  F,  A  },  and  an  object  proof  of  the  following  form: 


-Pi  V2 
[{]IU]A  [{}/R]A 


- p  - p 

E{r)  n  =  £(r)  n  t/  =  s  tel  S,[U\{s]/U][riSRU  {s}/R]A 

Va  V4 

[rH)R/R]A  [r\^R/R]A 

— — - INDdf'’ 

^{V,E)  .W  .^R.{U  CV  A  RCV)dA 


extract  an  object  program  of  the  following  form: 
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f\m  f  G  empty  R  -  ei 
I  f  G  U  empty  =  62 
I  f  G  U  (R  as  (r++R’))  = 
case  (mapp(r,G)  tt  U)  of 
empty  *>  [(f  G  U  R’)/p]e3 
(s++S)  =>  [(f  G  (U  —  s)  (s++R))/p)e4 

The  subexpressions  ei . . .  C4  are  given  by  the  following  premises  for  the  extraction.  The  notations 
.[J.®  and  and  indicate  the  extraction  judgments  for  graphs  and  finite  sets,  respectively.  Different 
fonts  distinguish  variables  of  the  logic  (i)  from  variables  of  the  programming  language  (x). 


•  Inf  A  (A  is  informative) 


((r,Gj)3G,iZ))^R),A)l- 


Vi 

[{}/U]A 


({T,GpG,Ui^^V),A)\- 


V2 

[{}/R]A 


he2 


•  <  (r,  G  G,  U,  iZ  R,  r  r,  5  S,  s  ^  s),  ( A, 

E{r)n/={}  A  A 
[r^R/R]A 


E{r)  n  [/  =  {}  A  A 


-IJ-sP)  ) 


( (r,  G  G,  C/ U,  iZ  R,  r  r,  5  S,  s  s), 


(A, 


f;(r)  n  =  s  W  5  A  [C^\{s}/CA][rWfl  U  {s}/i?]A 


^*P)) 


I  f;(r)  n  t/ =  s  l±l  5  A  [c/\{s}/c/][rlilfl  U  {«}//?] A 

^4 

[r  li)  R/R]A 


■iJ’s 


With  the  derivation  of  inDdf  we  can  transform  Proof  5.36  to  a  similar  proof  based  on  the 
new  induction  rule  inDdf-  The  extraction  procedure  sketched  above  yields  a  new  program  that 
improves  on  Program  5.37  in  two  ways.  The  extraneous  termination  parameter  has  been  removed. 
In  addition,  because  the  derived  induction  rule  corresponds  to  two  nested  inductions,  the  new 
program  contains  only  one  local  recursive  definition  instead  of  two. 
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Program  5.40 

fun  tclos’  (G  as  (graph(V,E)))  R  - 
let  fun  tclos.l’  G  empty  R  =  empty 
I  tclos.l’  G  U  empty  =  empty 
I  tclos.l’  G  U  (R  as  (r++R’))  = 
case  (mapp(r,G)  kk  U)  of 
empty  =>  (tclos.l’  G  U  R’) 

I  (s++S)  -> 

(s  ++  (tclos.l’  G  (U  —  s)  (s++R))) 
in  (tclos.l’  G  V  R)  end 


5.2.3  A  transformation  to  reflexive  transitive  closure 

Lemma  5.26,  which  says  that  E*(R)  =  E'^{R)  U  U  for  any  R  CV,is  the  basis  for  an  easy  proof 
for  reflexive  transitive  closure.  This  proof  contains  Proof  5.34  as  a  subproof. 

Specification  5.41  V(  )  ;  graph, /Z.iZ  CV  o3X  .X  =  E*{R) 

The  proof  proceeds  by  generalization  in  the  same  way  as  for  the  transitive  closure  Specification  5.32: 

Lemma  5.42  V(  V,E  ) :  gT&ph,U,R  .U,R  C  V  D  3X  .X  =  R\J  ^{R) 

Specification  5.41  follows  easily  with  U  =  V  hy  Lemma  5.26. 


Proof  5.43  (of  Lemma  5.42)  The  proof  is  trivial;  by  Lemma  5.33  there  is  a  set  VP  =  Ey{R);  form 
the  set  R  U  W.  □ 

The  extracted  program  relies  on  the  local  function  definition  tclos_l  ’  of  Program  5.40,  extracted 
from  Proof  5.34: 

Program  5.44 

fun  rtclos  (G  as  (graph(V,E)))  R  * 
let  fim  tclos.l  G  empty  R  =  empty 
I  tclos.l  G  U  empty  =  empty 

I  tclos.l  (G  as  graph(V,E))  U  (R  as  (r++R’))  = 
case  ((mapp(r,G))  kk  U)  of 
empty  =>  (tclos.l  G  U  R’) 

I  (s++S)  => 

(s  ++  (tclos.l  G  (U  —  s)  (s++R))) 
in  R  I  I  (tclos.l  G  V  R)  end 
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A  finite  differencing  transformation 

The  transformation  problem  in  this  example  is  a  special  case  of  finite  differencing  [PK80].  Proof  5.43 
gives  the  reflexive  transitive  closure  of  a  set  A  as  the  union  of  R  and  its  transitive  closure;  finite 
differencing  can  be  used  to  compute  the  union  incrementally.  As  a  program  tramsformation,  finite 
differencing  applies  when  there  is  a  difference  equation  expressing  incremental  computation,  such  as 
( A  U  {  a  })  U  B  =  { A  U  5 )  U  {  a  }.  This  section  shows  how  to  use  such  equations  at  the  level  of  proofs 
in  an  analogous  way.  The  transformation  is  very  similar  to  the  tail-recursion  transformation;  in 
fact,  the  analysis  of  the  inductive  subproof  is  identical  to  the  analysis  for  tail-recursion  introduction. 
This  is  not  surprising  since  both  are  instances  of  promotion,  as  pointed  out  in  [Bir84]. 

The  problem  in  this  particular  form  of  finite  differencing  is  to  distribute  the  computation  of  set 
union  over  a  recursive  function  definition.  A  proof  transformation  for  this  purpose  can  be  formulated 
for  any  simple  induction  principle  iNDs  (Definition  5.11).  It  operates  on  a  proof  containing  an 
inductive  subproof  and,  like  the  tail-recursion  transformation,  requires  proofs  of  lemmas  for  each 
case  of  the  induction.  Since  it  is  based  on  equations,  it  is  somewhat  simpler  to  specify.  As  usual 
we  describe  it  in  terms  of  higher-order  patterns. 

In  what  follows  we  abbreviate  the  parameters  and  terms  of  thf'  given  induction  principle  by 
tuple  variables.  Thus  denotes  the  parameters  of  induction  Xi , . . . ,  x„,  and  dj„  denotes  the  terms 
dii , . . . ,  din  occurring  in  an  induction  hypothesis,  etc. 

The  input  proof  has  the  form 

Proof  schema  5.45 


VlSD 

Vx„.P  D  3z.^{Xn,z) 

V 

Vx„  .P  D  3y.’9{xj^,y) 

where  "Dind  terminates  in  an  application  of  the  simple  induction  rule  iNDs.  As  usual,  double 
horizontal  lines  abbreviate  sequences  of  obvious  introduction  or  elimination  inferences.  We  will  use 
the  subproof  V  to  form  an  auxiliary  specification  for  a  new  inductive  subproof  in  the  style  of  the 
tail  recursion  transformation.  The  transformed  induction  will  prove 

Vx„.P  D  3y.-i-i32.^(xn»2)  A  y  =  g(x„,x) 

However,  the  presentation  follows  the  same  format  as  that  for  the  tail- recursion  transformation: 
first  we  describe  a  transformation  that  produces  an  inductive  subproof  without  double  negation. 
The  double  negation  transformations  of  Section  4.3  can  then  be  applied  to  selected  subproofs  of 
the  result  to  eliminate  unwanted  computation. 
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We  repeat  the  patterns  describing  the  inductive  subproof  of  the  input  proof  from  Section  5.1.4, 
changing  some  parameter  names  for  convenience. 

Each  base  case  of  "Disc  has  the  following  form,  where  a:i , . . . ,  r„  may  occur  free  in  t,i , . . . ,  t,„: 

Proof  schema  5.46 

Bi 

♦(*.n,f.(in)) 

32  •♦(tin, 2) 

Each  inductive  case  Vi  has  the  following  form,  where  the  proper  parameters  pii, . . .  ,Pij  of  Vi  may 
occur  free  in  Cij ...  Oi/c ,  d,! , . . . , din,  and  tii, . . .  ,tin* 

Proof  schema  5.47 

—  —  — r - gi 

Cii  ...  CiJt  ^(din,5^) 

Xi 

♦(tin,  f«(Pij»  ^)) 

32.^(din,2)  32.^(ti„,2) 

- - - 3E9. 

3z  .  ♦(tin,  2) 

For  each  case  Vi  of  the  induction  the  transformation  requires  a  proof  Ci  of  an  equation.  For  a  base 
case  Ci  must  prove,  for  some  hi  and  for  all  in. 

hi(in)  —  8(tin,  fi(^n)) 

For  an  inductive  case  Ci  must  prove,  for  some  hi  and  for  all  pij  and  z: 

hi(Pij,8(din,  =  8(tin,fi(Pij,  2)) 

This  equation  is  used  with  the  induction  hypothesis  when  constructing  an  inductive  case  of  the 
output  proof  to  provide  a  witness  <  for  3y .  p  =  g(ti„,  fi(pij,  2)).  The  witness  term  is  hi(pij,  y)  where 
y  is,  in  turn,  the  witness  provided  by  the  induction  hypothesis.  Thus  hi  should  be  chosen  so  that  it 
is  cheap  to  compute,  compared  to  the  cost  of  g(r„,  2).  For  the  transitive  closure  problem,  assuming 
a  cost  of  (|i4|  + 15|)^  for  A\J  B,  the  cost  of  hi  should  be  no  more  than  a  constant  since  the  induction 
principle  results  in  a  IV"!*  algorithm.  As  expected  (since  depth-first  search  is  inherently  |Fp  in  time 
complexity)  for  this  example  the  transformation  does  not  produce  an  asymptotic  improvement  in 
the  execution  time  of  the  algorithm. 

The  transformation  yields  a  proof  of  the  original  specification,  containing  an  inductive  subproof 
of 

.P  D  3y  .32.#(x„,2)  A  y  =  g(i,,,2) 

The  cases  of  the  induction  are  constructed  from  the  cases  of  the  original  induction  subproof  and 
the  lemmas  Ci. 

Each  base  case  of  the  induction  is  constructed  as  follows: 


\u 


Proof  schema  5.48 


*(t.n,f.(Xn))  h.(jn)  =  8(tm,fi(^n)) 

^(^tn>f|(®n))  ^  hj(®n)  =  8(^«n» fi(®n)) 


3y.a2.^(t.„,z)  A  y  =  g(t,„,2) 


Each  inductive  case  has  the  form: 

Proof  schema  5.40 


Cji  . .  .  Cilc  4(<l,'nt  -2^) 


-g.,AEH  h,(po,g(d,n,2)) 
y  =  g(d.n,2) _ =  g(t.n,f.(po,g)) 

ht(P0,P)  =  g(tm,f.(p.>,2)) 


3p.  32.  ♦(din,  2)  A  P  =  g(d,n,2) 


A  h.(p.j,y)  =g(t.>„f.(p.j,2)) 
3y.32.$(t,„,2)  A  y  =  g(t,„,2) 


3y.32.'#(ti„,2)  A  P  =  g(t,n,«) 


The  new  proof  has  the  form: 

Proof  schema  5.50 


»(jn,-g)  A  y  =  giXn,z) 
HXn,z) 


$(x„,2)  A  y  =  g(x„,2) 


y  =  g(Xn,x) 


’®'(®n,g(Xn,x)) 


Vx„.P  D  3y.32.^(x„,2)  A  y  =  g(Xn,2) 


$(x„,2)  A  y  =  g(x„,2)  D  «'(z„,y) 


^(x„,2)  A  y  =  g(x„,2) 


’*'(x„,y) 


Vx„.P  D  3y.’9?{x„,y) 


Applying  finite  differencing  to  depth-first  search 

We  now  show  how  the  transformation  can  be  applied  to  Proof  5.34.  Matching  this  proof  against 
Proof  schemas  5.45  through  5.47  yields  the  following  instantiations: 
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•  g  :  AV .  XE .  XU .  XR  .Xr.R  U  r 

•  From  the  first  base  case: 

-  tin  : 

-  fi  :  XV.XE.XU.XR.{} 

•  From  the  second  base  case: 

-i2n:V,E,U,{} 

-  fj  :  XV  .XE.XU  .XR.{} 

•  From  the  first  inductive  case: 

-  p3j  :  V,  E,  U,  R,  T 

-  dan  :  V,E,U,R 

-  tan  :  V,E,U,r\^R 

-  fa  :  XV  .XE.XU  .XR.Xr.Xy.y 

•  From  the  second  inductive  case: 

-  p4j  :  V,E,U,R,r,s,S 

-  d4n:  V,E,U\{s},{r\tl  R)U  {s} 

-  t4„  :  V,E,U,r\ilR 

-  U  ■■  XV  .XE.XU  .XR.Xr.Xs.XS.Xy.{s}  U  y 

With  these  instantiations  we  are  in  a  position  to  examine  the  proof  obligations  (the  equations) 
for  the  four  cases  of  the  induction. 

1.  Cl  must  prove 

hi{V,  E,U,R)  =  RU{} 

for  some  hi ;  the  obvious  choice  is  XV  .XE.XU  .XR.  R,  so  the  proof  obligation  becomes 

yR.R  =  RU  {} 

which  is  trivial  to  prove. 

2.  £2  must  prove 

h2{V,E,U,R)  =  {}  U  {} 

so  we  choose  the  constant  function  yielding  {)  for  h2,  and  again  have  a  trivial  proof  obligation 
of{}  =  {}u{}. 

3.  For  £a  the  user  must  find  some  ha  so  that  for  any  z 

ha( V, E, U,R,r,RV  z)  =  (r  W  i?)  U  z 

Choosing  AV .  XE .  XU  .  XR .  Ar .  Ay .  r  (+l  y  for  ha  leads  to  the  proof  obligation 

r  W  (.R  U  z)  =  (r  W  iZ)  U  2 

which  follows  easily  from  the  associativity  of  set  union. 
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4.  For  £4  the  user  must  find  some  h4  so  that  for  any  z 

Yi4{V,E,U,R^T,s,S,{{r  W  iZ)  U  {s  })  U  2)  =  (r  W  iZ)  U  ({s  }  U  2) 

Choosing  AV .  XE .  XU  .  XR  .Xr.Xs.XS.Xy.yforYii  leads  to  the  proof  obligation 

((r  W  iZ)  U  {s})  U  2  =  (rW  /Z)  U  ({«}  U  2) 
which  again  follows  easily  from  the  associativity  of  set  union. 

The  result  of  the  transformation  is  the  following  proof  of  Lemma  5.42; 

Proof  5.51  We  prove  the  following  lemma  by  induction  on  the  pair  of  sets  {U,R): 

Lemma  5.52 

\^{V,E).W  .^R.U,RCV  d3W  .3X  .X  =  RU  iJ(iZ)  A  W  =  R  U  X 

Case  U  =  {};  then  let  X  =  {}  and  W  =  iZ. 

Case  R  =  {};  then  let  AT  =  IF  =  {}. 

Case  U  ,1^  {},  iZ  =  r  l+l  iZ'.  There  are  two  cases: 

1.  Euir)  =  {}.  Then  apply  the  induction  hypothesis  to  {U,R')  to  obtain  X'  =  Eu^{R')  and 
W'  =  iZ'  U  X'. 

By  the  reasoning  of  Proof  5.34  Eu^{Rf)  =  Eu^{r  W  R').  So  let  X  =  W.  Thus  W  = 

R'  U  Eu^{r\^R').  Then  by  the  associativity  of  set  union  {r}  U  IF'  =  (rl+liZ')  U  E[j^{t^R'). 
So  let  IF  =  {r}  U  W. 

2.  Eu{r)  =  s  W  5.  Write  U'  for  U\{s}  and  apply  the  induction  hypothesis  to  {U\ .R  U  { s })  to 

obtain  X'  =  {Eu>^){R  U  {s})  and  IF'  =  (J2  U  {s})  U  W.  By  the  reasoning  of  Proof  5.34 

{s}UR^»‘^(iZ  U  {s})  =  ^'^{R).  SoletX  =  {s}uAr'.  Now  IF' =  (iZU  {s})  U  (^-“^KiZU 

{s})  =  iZ  U  ({s}  U  {Eu>^){R  U  {5}))  by  associativity.  Then  VF'  =  iZ  U  Eu^{R),  so  let 
W  =  W. 

Lemma  5.42  follows  trivially.  □ 

Once  the  proof  is  further  transformed  by  inserting  double  negations,  the  following  program  can 
be  extracted.  It  traverses  the  graph  in  depth-first  order,  adding  nodes  to  the  result  as  they  are 
removed  from  the  root  set  R.  This  corresponds  to  a  post-order  listing  of  a  depth-first  spanning 
forest  with  roots  in  R. 
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Program  5.53 

fun  rtclos’  (G  as  (graph(V,E)))  R  = 
let  fun  rtclos.l*  G  empty  R  »  r 

I  rtclos.l’  G  U  empty  =  empty 

I  rtclos.l’  (G  as  graph(V,E))  U  (R  as  (r++R’))  = 
case  ((mapp(r,G})  tt  U)  of 

empty  ®>  r  ++  (rtclos.l’  G  U  R’) 

I  (8++S)  -> 

(rtclos.l’  G  (U  —  s)  (s++R)) 
in  (rtclos.l’  G  V  R)  end 


5.3  Discussion 

The  two  case  studies  of  this  chapter  demonstrate  that  simple  proof  transformations  expressible  as 
derived  rules  of  the  object  logic  can  be  used  to  obtain  results  comparable  to  those  of  program  trans¬ 
formation  while  maintaining  a  formal  basis  (the  object  proof)  for  an  explanation  of  the  program. 
The  capability  of  proof  transformation  to  alter  the  functionality  of  the  extracted  program,  already 
seen  in  the  example  of  Chapter  4,  appeared  again  in  the  case  of  breadth-first  search.  However,  the 
significance  of  this  capability  remains  to  be  seen.  It  may  be  more  important  that  this  methodol¬ 
ogy  integrates  the  flexibility  of  a  transformational  approach  with  the  formal  connection  between  a 
program  and  its  specification  provided  by  the  proofs-as-programs  methodology. 

The  program  development  of  the  depth-first  search  case  study  can  be  duplicated  at  the  program 
level  by  fold-unfold  program  transformations  combined  with  Sasaki’s  dead  code  elimination  tech¬ 
nique  [Sas86].  Dead  code  elimination  would  produce  the  transitive  closure  function  Program  5.40 
from  Program  5.37.  The  developer  could  then  define  reflexive  transitive  closure  in  terms  of  set  union 
and  transitive  closure.  Fold-unfold  transformations  would  eventually  yield  our  final  program.  But 
a  proof  that  this  meets  the  specification  of  reflexive  transitive  closure  is  external  to  this  process, 
while  such  a  proof  is  integral  to  the  proof  transformation  approach. 

The  proofs  produced  by  the  transformations  of  the  case  studies  could  of  course  be  developed 
directly.  The  end  product  of  the  depth-first  search  development,  in  particular,  is  no  more  com¬ 
plicated  or  difficult  to  understand  than  the  initial  proof.  Part  of  the  point  of  the  example  is  to 
show  how  transformations  can  be  used  to  avoid  re-doing  a  proof  from  the  beginning  when  the 
specification  changes  slightly.  The  transformation  isolates  proof  obligations  so  that  a  user  does  not 
need  to  repeat  the  theorem-proving  tasks  already  done.  Where  the  end  product  of  the  develop¬ 
ment  is  more  complex  than  the  “natural  proof,”  a  record  of  the  transformations  used  to  obtain  it 
may  be  useful  as  a  formal  basis  for  documentation  of  the  extracted  program.  The  proof  for  the 
tail-recursive  form  of  breadth-first  search  is  a  small  example  of  this:  to  an  uninformed  reader  the 
presence  of  the  accumulator  parameter  requires  explanation.  A  large,  highly  optimized  proof  will 
likely  contain  many  such  obscure  points.  Keeping  such  a  record  would  amount  to  lifting  the  design 
record  advocated  in  [SS83]  from  the  domain  of  programs  to  the  domain  of  proofs. 


Chapter  6 

Conclusion 


This  chapter  summarizes  the  thesis  and  discusses  some  directions  for  further  research. 

6.1  Summary 

This  work  has  explored  a  transformational  extension  to  the  proofs-as-programs  methodology.  We 
have  focused  on  a  declarative  formulation  of  proof  transformations  and  a  partially  verified  imple¬ 
mentation  based  on  a  logical  framework  and  higher-order  logic  programming.  Our  case  studies  show 
that  known  program  transformations  can  be  translated  into  the  domain  of  proofs  in  the  form  of  de¬ 
rived  rules  of  the  object  logic.  In  the  case  of  tail  recursion  introduction,  we  demonstrated  the  effect 
noted  by  Goad  for  the  case  of  specialization:  the  increased  power  of  such  a  proof  transformation 
over  its  corresponding  purely  syntactic  program  transformation. 

We  gave  an  implementation  of  the  core  of  the  support  for  programming  as  theorem- proving:  a 
constructive  logic,  the  syntaix  and  semantics  of  a  small  functional  programming  language,  and  the 
extraction  of  programs  from  proofs.  There  are  far  more  advanced  systems  capable  of  supporting 
programming  by  theorem  proving,  and  they  are  increasing  rapidly  in  sophistication.  But  these 
systems  are  committed  to  a  particular  logic  and  programming  language  and  provide  limited  support 
for  verified  metaprogramming.  The  framework  approach  allows  for  rapid  experimentation  with 
various  object  logics,  programming  languages,  notions  of  program  extraction,  and  metaprograms. 

The  implementation  is  concise  and  was  easy  to  develop  largely  because  of  an  intensive  use 
of  higher-order  abstract  syntax.  This  was  possible  because  of  the  choice  of  logic,  programming 
language,  and  the  kind  of  proof  transformations  to  be  treated.  However,  it  is  important  to  stress 
that  the  use  of  a  logical  framework  is  not  restricted  to  cases  where  higher-order  abstract  syntax  is 
an  appropriate  technique. 

We  have  shown  how  our  choice  of  implementation  strategy  supports  verified  metaprogramming. 
Proofs  of  correctness  properties  of  program  extraction  were  partially  internalized  as  Elf  programs 
in  such  a  way  that  type  checking  of  the  programs  amounts  to  the  checking  of  the  constructive  parts 
of  the  proofs.  We  encoded  proof  transformations  as  rewrite  rules  so  that  their  type-correctness 
is  equivalent  to  a  proof  that  they  are  derived  rules  of  the  object  logic.  This  style  of  encoding 
gives  a  strong  guarantee  of  correctness,  not  only  for  the  result  of  a  particular  application  of  the 
transformation,  but  for  the  transformation  itself. 
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While  we  have  not  given  a  formal  method  for  the  translation  of  known  program  transformations 
to  the  domain  of  proofs,  the  ca^e  studies  demonstrate  that  such  translation  is  feasible,  and  that 
the  result  is  likely  to  be  expressible  as  a  derived  logical  rule.  We  gave  rules  in  this  form  for 
transformations  to  introduce  tail-recursive  structure,  to  perform  finite  differencing,  and  to  change 
the  basis  of  a  recursive  definition,  and  applied  them  to  several  small  programming  problems  on  bsts, 
trees,  and  directed  graphs.  Our  study  of  tail- recursion  showed  that  proof  transformation  resulted  in 
a  useful  change  to  the  functional  behavior  of  the  extracted  program,  which  would  not  be  obtained 
by  syntactic  program  transformations  that  preserve  functionality.  Although  Goad  demonstrated 
this  effect  for  specialization,  we  do  not  know  of  any  other  examples  in  the  literature. 


6.2  Assessment 


The  implementation  and  case  studies  are  evidence  that  metaprograms  for  treating  proof  systems 
can  be  easily  implemented  in  a  declarative  way  that  lends  itself  to  verification,  and  effectively 
applied  to  useful  tasks  in  program  development. 

Although  we  used  a  very  simple  object  logic,  in  principle  the  approach  is  independent  of  this 
choice.  While  encodings  of  richer  logics  or  special-purpose  logics  are  not  necessarily  trivial  to 
achieve,  there  is  a  wide  range  of  choice  even  with  the  particular  framework  we  used.  Given  the 
current  interest  in  variations  on  logics  and  programming  languages  for  proofs- as- programs  (e.g. 
[Mur90],  [PW90],  [Raf93]),  the  implementation  methodology  demonstrated  here  can  be  a  valuable 
aid  to  research. 

The  methodology  we  used  can  work  with  a  wide  variety  of  theorem- proving  tools.  The  only 
requirement  is  that  proof  objects  can  be  generated  by  liie  proof  process.  Thus  it  could  be  used  in 
conjunction  with  interactive  proof  assistants  such  as  Coq  o.  .Vuprl,  or  with  the  addition  of  proof 
objects,  automated  deduction  systems  like  the  Boyer-Moore  prover  [BM79]  or  provers  that  are 
components  of  larger  systems  like  the  software  development  system  KIDS  [Smi91]. 

The  potential  of  our  approach  is  not  limited  to  applications  to  program  development  by  the 
proofs-as-programs  methodology,  or  to  programming  in  the  small,  or  even  to  programming.  It 
can  be  used  wherever  the  adaptation  and  reuse  of  formal  deductions  is  of  interest.  With  further 
research,  the  use  of  proof  transformations  could  have  an  impact  on  methodologies  and  support 
tools  for  a  variety  of  tasks  where  formal  proof  is  important.  This  impact  will  come  primarily  from 
the  fact  that  proof  transformation  offers  support  for  the  modification  and  reuse  of  formal  proofs 
that  provide  a  basis  for  verification  and  documentation,  reducing  the  cost  of  these  activities.  The 
framework- based  implementation  strategy  used  in  this  thesis  provides  the  flexibility  and  ease  of 
programming  necessary  to  support  experimentation  in  new  areas  of  application.  The  variety  of 
possible  settings  in  which  it  will  be  interesting  to  explore  the  use  of  proof  transformation  is  an 
argument  in  favor  of  our  implementation  strategy,  at  least  as  a  basis  for  research.  Its  flexibility 
and  independence  of  the  choice  of  logic  and  theorem-proving  tools  can  support  quite  different  lines 
of  research,  yet  allow  sharing  of  techniques  between  them. 
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6,3  Future  work 

The  implementation  described  here  could  be  improved  and  extended  in  a  number  of  ways.  The  work 
of  Felty  [Fel89]  on  the  specification  and  implementation  of  theorem  provers  in  the  closely  related 
setting  of  AProlog,  combined  with  our  work,  would  provide  a  basis  for  a  complete  implementation 
in  Elf  of  support  for  programming  by  theorem  proving.  The  tacticals  she  developed  for  theorem 
provers  in  AProlog  could  be  adapted  to  the  problem  of  high-level  control  of  the  proof  transformation 
process. 

Planned  extensions  to  the  Elf  language  promise  improved  support  for  the  structuring  of  object 
languages,  theories,  and  metaprogiams.  The  module  system  of  [HP99]  would  greatly  ease  the  task 
of  creating  and  maintaining  a  scaled-up  implementation,  by  providing  name-space  management 
ajid  explicit  representation  of  the  relations  between  deductive  systems  in  the  form  of  parametrized 
signatures  and  realizors.  Intersection  types  as  proposed  in  [Pfe92b]  could  be  used  to  decrease  the 
duplication  of  code  in  the  encoding  of  many-sorted  first-order  logic. 

While  the  expression  of  a  proof  transformation  as  a  derived  logical  rule  has  advantages  for 
expressiveness  and  automatic  verification,  it  is  too  specific.  For  instance,  tail  recursion  introduction 
had  to  be  encoded  separately  for  different  induction  principles,  and  the  encoding  is  also  sensitive  to 
different  case  analysis  structures  in  the  input  proof.  The  generality  of  the  transformations  can  be 
increased  by  coding  them  as  logic  programs  that  handle  a  class  of  proof  structures,  but  at  the  cost 
of  conciseness  and  declarative  form.  A  general  treatment  of  induction  for  the  object  logic  along 
the  lines  of  Hayashi’s  conditional  inductive  generations  [Hay90]  or  the  inductively  defined  types 
of  Coq  [PM93]  might  be  one  way  to  attack  this  probleih.  It  would  also  be  interesting  to  try  to 
formulate  transformations  as  signatures  parametrized  to  a  particular  induction  principle  using  the 
proposed  Elf  module  system. 

Our  formulation  of  proof  transformations  does  not  completely  specify  the  associated  theorem¬ 
proving  obligations.  In  most  cases  the  transformation  represents  an  obligation  as  a  pattern  which 
is  only  partially  instantiated  by  unification  with  the  input  proof.  Peter  Madden  has  shown  in  his 
thesis  that  similar  problems  for  the  tupling  transformation  can  be  solved  by  heuristics  and  analysis. 
This  work  could  certainly  be  extended  to  our  implementation  framework. 

Further  experimentation  with  case  studies  will  be  required  to  understand  the  potential  value  of 
proof  transformation  for  the  program  development  process.  It  would  be  valuable  to  find  a  char¬ 
acterization  of  circumstances  in  which  proof  transformation  can  do  more  than  syntactic  program 
transformation.  The  tail-recursion  examples  that  we  studied  produced  a  change  in  the  functionality 
of  the  extracted  program.  But  as  we  noted,  this  would  not  occur  if  the  problems  were  specified 
on  the  domain  of  sets  rather  than  lists,  because  the  corresponding  functions  on  sets  are  equal. 
The  specification  in  terms  of  lists  may  be  thought  of  as  arising  from  a  commitment  to  a  particular 
concrete  data  type;  from  this  perspective  the  proof  transformation  is  a  tool  for  recovering  from  a 
premature  commitment,  a  common  problem  in  software  maintenance. 

Further  case  studies  could  also  reveal  to  what  extent  proof  transformations  can  syntactically 
capture  heuristics  and  semantic  side  conditions  for  program  transformations.  Since  a  proof  de¬ 
scribes  formally  how  a  program  implements  its  specification,  it  may  contain  more  clues  to  how 
the  program  can  be  transformed  than  the  program  itself  does.  As  we  have  seen,  proof  transforma¬ 
tions  necessarily  capture  proof  obligations  for  a  program  transformation.  Perhaps  existing  program 
transformation  approaches  could  be  enriched  with  a  proof-transformational  formulation  that  would 
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provide  a  uniform  language  for  expressing  some  heuristic  knowledge  and  all  of  the  semantic  cor¬ 
rectness  criteria. 

These  case  studies  should  ideally  explore  hard  program  development  problems  like  those  treated 
by  the  state-of-the-art  program  transformation  and  synthesis  research.  This  will  require  a  richer 
object  logic  than  was  used  in  this  work,  such  as  Nuprl  or  Constructions,  as  well  as  good  proof 
development  tools. 

One  way  to  attack  such  examples  would  be  to  do  the  work  entirely  within  a  proof  development 
system  like  Coq,  implementing  proof  transformations  in  the  ML  metalanguage.  Although  the 
metaprograms  would  be  less  easily  verified  and  less  declarative  in  style  than  the  encodings  developed 
in  this  thesis,  this  approach  could  lead  to  insights  into  how  such  proof  development  systems  can 
support  the  reuse  and  adaptation  of  proofs  in  general,  not  only  proofs  of  programs.  A  variation  on 
this  approach  would  be  to  use  the  chosen  system  for  theorem-proving  but  interface  it  to  a  framework 
like  Elf  where  proof  transformations  could  be  more  easily  represented  and  verified. 

An  alternative  line  of  research  is  to  view  proof  transformation  as  an  enrichment  of  program 
transformation,  and  to  build  more  directly  on  research  in  that  area.  For  example,  many  features  of 
Smith’s  KIDS  system  [Smi91]  could  in  principle  be  recast  as  proof  constructions  and  proof  trans¬ 
formations.  Theorem-proving  in  this  system  is  accomplished  by  goal-directed  inference,  driven  by 
the  needs  of  the  programming  problem  at  hand.  This  approach  to  proof  fits  well  with  the  way  proof 
transformations  impose  proof  obligations.  Directed  inference  may  be  well-suited  to  the  problem 
noted  above  of  fully  instantiating  proof  obligations,  as  weU  as  that  of  fulfilling  those  obligations. 
Some  of  the  optimizations  of  KIDS  have  already  been  translated  to  the  domain  of  proofs,  for  ex¬ 
ample  specialization  (by  Goad)  and  finite  differencing  (in  this  thesis).  The  treatment  of  abstract 
data  types  suggested  by  Pfenning  [Pfe90]  could  probably  be  used  as  a  proof-transformational  basis 
for  the  data  type  refinement  feature  of  KIDS.  Implementing  the  major  features  of  a  system  like 
KIDS  in  a  proofs-as-programs  setting  augmented  with  proof  transformations  would  be  a  hard  but 
rewarding  task.  Because  KIDS  contains  a  great  deal  of  programming  knowledge  and  high-level  op¬ 
erators,  such  an  implementation  would  provide  significant  help  with  case  studies  of  the  application 
of  the  proofs-as-programs  methodology  to  difficult  programming  problems.  Proof  objects  could 
provide  a  uniform  framework  for  the  representation  of  the  information  that  is  exploited  at  each 
development  step.  This  is  potentially  valuable  for  both  the  correctness  of  the  implementation  of 
the  transformation  system  and  the  documentation  of  the  program  development  process. 


Appendix  A 

Elf  encodings  from  Chapter  2 


All  Elf  code  in  this  thesis  is  accessible  (at  the  time  of  writing)  by  anonymous  ftp  from  Carnegie 
Mellon  University.  To  obtain  the  code: 

X  ftp  ftp.cs.cmu.edu 
Name:  anon3rmous 

Password:  (your  e-mail  address) 
ftp>  cd  /afs/cs/user/apa/ftp 
ftp>  type  binary 
ftp>  get  thesis-elf .tar. Z 
ftp>  bye 

X  uncompress  thesis-elf .tar. Z 
X  tar  -xvf  thesis-elf .tar 
X  rm  ♦.tar 

(ftp.cs.cmu.edu  has  internet  address  128.2.206.173) 

This  will  create  a  directory  proof-trans/  with  the  Elf  code  and  examples  in  various  subdirectories. 
For  the  Elf  implementation  itself  see  the  file  /afs/cs/user/fp/public/README. 


A.l  First-order  logic  and  arithmetic 

X'/tX  First-order  constructive  logic. 

XXX  Static 

XXX  Propositions. 

XXX  Syntactic  categories. 

o  :  type.  Xnarae  o  A  B  C 

i  :  type.  Xname  i  T1  T2  T3 

XXX  Syntax. 
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true  :  o. 
laO-se  :  o. 
not  ;  o  ->  o. 
and  :  o  ->  o  ->  o. 
or  :  o  ->  o  ->  o. 
implies  :  o  ->  o  ->  o. 
forall  :  (i  ->  o)  ->  o. 
exists  :  (i  ->  o)  ->  o. 

*1X1,  Proofs 

I-  :  o  ->  typo.  Xname  I-  P  Q  PI  P2  P3  Q1  IJ2  (J3 

truei  :  I-  true. 

fzilsee  :  {C:o}  |-  false  ->  |-  C. 


andi  :  |-  A  ->  |-  B  ->  I-  (and  A  B). 
2uidel  :  |-  (and  A  B)  ->  I-  A. 
ander  :  I-  (and  A  B)  ->  I-  B. 


oril  :  {Bro}  |-  A  ->  |-  (or  A  B). 
orir  :  {A:o}  |-  B  ->  |-  (or  A  B). 

ore  :  (I-  A  ->  |-  C)  ->  (I-  B  ->  |-  C)  ->  |-  (or  A  B)  ->  |-  C. 


impliesi  :  (I-  A  ->  |-  B)  ->  I-  (implies  A  B). 
impliese  ;  I-  (implies  A  B)  ->  I-  A  ->  I-  B. 

noti  :  (I-  A  ->  |-  f^ase)  ->  |-  (not  A), 
note  :  I-  (not  A)  ->  |-  A  ->  I-  false. 

foralli  :  ({x:!}  I-  (Ax))  ->  I-  (forall  A), 
forallo  :  {T:!}  |-  (forall  A)  ->  I-  (A  T). 


exists!  :  {A:i  ->  o}  {T:i}  |-  (AT)  ->  |-  (exists  A), 
existse  :  ({x:i>  |-  (Ax)  ->  I-  C)  ->  I-  (exists  A)  ->  I-  C. 

'1X1%  Interpret  "i"  of  FOL  as  natural  numbers. 

'1X1%  Static. 


zero  :  i. 
succ  :  i  ->  i. 

•/.*/.  Equadity 

eq  :  i  ->  i  ->  o. 

eq.rofl  :  {X:i}  1-  (eq  X  X). 

eq.sym  :  |-  (eq  X  Y)  ->  |-  (eq  Y  X). 

eq_trans  :  |-  (eq  X  Y)  ->  I-  (eq  Y  Z)  ->  |-  (eq  X  Z). 

eq_subst  :  {F:i  ->  i}  1-  (eq  X  Y)  ->  I-  (eq  (F  X)  (F  Y)). 
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ax_zero  :  {X:!}  I-  (not  (eq  (succ  X)  zero)). 

ax.succ  :  {X:i}  {Y:!}  |-  (eq  (succ  X)  (succ  Y))  ->  |-  (eq  X  Y). 

VX  Induction 

ind  :  {A:!  ->  o}  I-  (A  zero)  ->  ({x:!}  I-  (Ax)  ->  |-  (A  (succ  x))) 
->  |-  (forall  A). 


A.2  Functional  programming  language 

V/X  Abstract  syntax  of  terms  and  types. 

V/X,  Static. 

tp  :  type, 
term  ;  type. 

arrou  :  tp  ->  tp  ->  tp. 

app  :  term  ->  term  ->  term, 
lam  :  (term  ->  term)  ->  term, 
lix  :  (term  ->  term)  ->  term. 

unit  :  tp. 
unity  :  term. 

nat  :  tp . 

0  :  term. 

s  :  term  ->  term.  '/.prefix  100  s 

nat.ind  :  term  ->  (term  ->  term  ->  term)  ->  term. 

*  :  tp  ->  tp  ->  tp. 

pair  :  term  ->  term  ->  term. 

fst  ;  term  ->  term. 

snd  :  term  ->  term. 

spread  :  term  ->  (term  ->  term  ->  term)  ->  term. 

I  :  tp  ->  tp  ->  tp. 
ini  :  term  ->  term, 
inr  :  term  ->  term. 

decide  :  term  ->  (term  ->  term)  ->  (term  ->  term)  ->  term. 

void  :  tp. 

any  :  term  ->  term. 

neg  :  term. 

atom  :  tp. 
axiom  :  term. 


'/Aame  tp  Tp  Tp  ’  Tp  ’ ' 
‘/Aame  term  N  I  M’  H'  M" 


%%%  Call-by-valua  natural  senantics. 
aval  :  term  ->  tarn  ->  typa. 
av_0  :  aval  0  0. 

av_8  :  aval  (s  M)  (s  V)  <-  aval  M  V. 

®v_pair  :  aval  (pair  MI)  (pair  V  V*)  <-  aval  M  V  <-  aval  IV’. 
av.spraad  :  aval  (spraad  M  I)  V 

<-  aval  M  (pair  VI  V2) 

<-  aval  (I  VI  V2)  V. 

av_lst  :  aval  (fat  M)  VI  <-  aval  M  (pair  VI  V2). 

av_snd  :  aval  (and  M)  V2  <-  aval  M  (pair  VI  V2) . 

av_inl  :  aval  (ini  M)  (ini  V)  <-  aval  M  V. 

av_inr  :  aval  (inr  M)  (inr  V)  <-  aval  M  V. 

av_dec_l  :  eveil  (dacida  M  II  Ir)  V 
<-  aval  M  (ini  V') 

<-  aval  (II  V’)  V. 
av_dac_r  :  aval  (dacida  M  II  Ir)  V 
<-  aval  M  (inr  V’) 

<-  aval  (Ir  V’)  V. 

av.lam  :  aval  (lam  M)  (lam  N) . 
av.app.lam  :  aval  (app  N  I)  V 
<-  aval  M  (lam  M’) 

<-  aval  I  VI 
<-  aval  (M’  VI)  V. 

av_pr  :  aval  (nat.ind  MO  Ms)  (nat_ind  MO  Ms). 

«v_pr_z  :  aval  (app  M  I)  V 

<-  aval  M  (nat_ind  MO  Ms) 

<-  aval  I  0 
<-  aval  MO  V. 

av_pr_a  :  aval  (app  M  I)  V 

<-  avsQ  M  (nat.ind  MO  Ms) 

<-  aval  I  (si’) 

<-  aval  (Ms  I’  (app  (nat_ind  MO  Ms)  I’))  V. 

sv_unity  :  aval  unity  unity. 
av_axiom  :  aval  axiom  axiom, 
av.nag  :  aval  nag  nag. 

'/X/t  Typa  infaranca. 


of  :  tarm  ->  tp  ->  t3rpa. 
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tp_0  :  of  0  nat. 

tp_>  :  of  (a  N)  nat  <-  of  N  nat. 

tp.pair  :  of  (pair  MI)  (*  A  B)  <-  of  M  A  <-  of  1  B. 
tp.fat  :  of  (fat  N)  A  <-  of  N  (*  A  B) . 

tp_and  :  of  (and  N)  B  <-  of  N  (*  A  B) . 

tp.apraad  :  of  (apraad  Npr  I)  C 
<-  of  Mpr  (*  A  B) 

<-  {x}  of  X  A  ->  -Cy}  of  y  B  ->  of  (I  X  y)  C. 

tp.inl  :  {B>  of  (ini  M)  (I  A  B)  <-  of  M  A. 

tp_inr  :  {A}  of  (inr  M)  (I  A  B)  <-  of  M  B. 

tp.decida  :  of  (decide  N  II  Ir)  C 
<-  of  N  (I  A  B) 

<-  ({x:tem>  of  x  A  ->  of  (II  x)  C) 

<-  ({x:teni}  of  x  B  ->  of  (Ir  x)  C). 

tp.lan  :  of  (laai  M)  (arrow  A  B) 

<-  {x:ten>  of  x  A  ->  of  (M  x)  B. 
tp_app  :  of  (app  M  I)  B  <-  of  M  (arrow  A  B)  <-  of  I  A. 

tp.prec  ;  of  (nat.ind  Mz  Ma)  (arrow  nat  A) 

<-  of  Mz  A 

<-  ({x>  of  X  nat  ->  {y}  of  y  A  ->  of  (Ma  x  y)  A). 

tp.nnity  :  of  unity  unit. 

tp.axioB  :  of  axiom  atom. 

tp.any  :  {A}  of  (any  M)  A  <-  of  M  void. 

tp_neg  :  {A}  of  neg  (arrow  A  void). 


A.3  Program  and  type  extraction 

Extraction  from  individual  terms  of  arithmetic, 
m  DYIAMIC 

extract _tm  :  i  ->  term  ->  type. 
ex_zero  :  extract _tm  zero  0. 

ex.succ  :  extract.tm  (succ  X)  (s  M)  <-  extract.tm  X  M. 


%%%  Extraction  of  fpl  functions  from 
intuitionistic  proofs. 


y.'/,y.  Dynamic. 
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•ztract  :  I-  A  ->  t«m  ->  typ«. 

:  extract  tmai  unity. 

ax.lalaaa  :  extract  (falsee  C  P)  (any  N)  <-  extract  P  M. 

ex.andi  :  extract  (andi  PI  P2)  (pair  Mi  N2) 

<-  extract  PI  Ml  <-  extract  P2  N2. 
ex_andel  :  extract  (andel  P)  (let  N)  <-  extract  P  N. 

ex.ander  :  extract  (ander  P)  (end  N)  <-  extract  P  M. 

ex.oril  :  extract  (oril  B  P)  (ini  M)  <-  extract  P  M. 

ex.orir  :  extract  (orir  A  P)  (inr  N)  <-  extract  P  M. 

ex.ore  :  extract  (ore  PI  P2  Q)  (decide  N  Ml  Mr) 

<-  extract  Q  N 

<-  (-Cx:!-  A}  -(vtter*}  extract  x  v  ->  extract  (PI  x)  (11  v)) 

<-  (-Cx:!-  B>  {v:tem>  extract  x  v  ->  extract  (P2  x)  (Ir  v)). 

ex_inpliasi  :  extract  (inplieei  P)  (laa  N) 

<-  <x:|-  A}  {v:ter«>  extract  x  v  ->  extract  (P  x)  (M  v) . 

ex_iaplie8e  ;  extract  (iaplieae  PI  P2}  (app  Ml  N2) 

<-  extract  PI  Ml  <-  extract  P2  M2. 

ex.noti  :  extract  (noti  P)  (Ian  M) 

<-  ■(x:l-  A>  {v:tem}  (extract  x  r  ->  extract  (P  x)  (M  v)). 
ex.note  :  extract  (note  PI  P2)  (app  Ml  M2) 

<-  extract  PI  Ml  <-  extract  P2  M2. 

Extraction  lor  arithmetic 

Dynamic. 

ex.loralli  :  extract  (loralli  P)  (lam  M) 

<-  <x:i}  •Cv:tem}  extract_ta  x  v  ->  extract  (P  x)  (M  v). 

ex_loralle  :  extract  (loralle  T  P)  (app  M  I) 

<-  extract  P  M  <-  extract _tm  T  I. 

ex.existsi  :  extract  (existsi  ATP)  (pair  I  M) 

<-  extract.tm  T  I  <-  extract  P  M. 

ex.existse  :  extract  (existse  P  Q)  (spread  1  M) 

<-  ({x:i}  ■{x’:tem}  extract _tm  x  x’ 

->  {p:|-  (A  x)}  {p’ltem}  extract  p  p’ 

->  extract  (P  x  p)  (M  x’  p’)) 

<-  extract  Q  I. 

ex.rell  :  extract  (eq.rell  X)  axiom, 
ex.sym  :  extract  (eq.sym  P)  axiom. 
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•x_traiis  :  axtract  (eq_trans  PI  P2)  axioa. 
•x.subst  :  extract  (eq_8ubst  F  P)  axiom. 
ex_ax_zero  :  extract  (ax.zero  X)  neg. 
ex.ax.succ  :  extract  (ax.succ  X  Y  P)  axioa. 

ex_ind  :  extract  (ind  i  Pz  P>)  (nat.ind  Iz  Is) 

<-  extract  Pz  Xz 

<-  ■Cx:i}  {Yttera}  extract.ta  x  v 

->  •(p:l-  (A  x)>  -Cvztera}  extract  p  a 
->  extract  (Ps  z  p)  (Is  v  a) . 


Extraction  of  fpl  types. 

Dynamic. 

extract.tp  :  o  ->  tp  ->  type. 

ext_tme  :  extract _tp  true  unit. 

ext.false  :  extract.tp  false  void. 

ext_not  :  extract.tp  (not  A)  (arroa  Tp  void) 

<-  extract .tp  A  Tp. 

ext.and  :  extract.tp  (and  A  B)  (*  Tpl  Tp2) 

<-  extract.tp  A  Tpl 
<-  extract _tp  B  Tp2. 

ext_or  :  extract.tp  (or  A  B)  (I  Tpl  Tp2) 

<-  extract.tp  A  Tpl 
<-  extract _tp  B  Tp2. 

ext.iaplies  :  extract.tp  (implies  A  B)  (arroa  Tpl  Tp2) 
<-  extract.tp  A  Tpl 
<-  extract _tp  B  Tp2. 

Extraction  of  fpl  types. 

%%%  Dynamic. 

ext.forall  :  extract.tp  (forall  A)  (arroa  nat  Tp) 

<-  -Cxri}  extract.tp  (A  x)  Tp. 

ext.exists  :  extract_tp  (exists  A)  (*  nat  Tp) 

<-  -(xri}  extract.tp  (A  x)  Tp. 

ext.eq  :  extract.tp  (eq  X  Y)  atom. 


A.4  Extraction/simplification 


XXX  Extraction/siaplilication  of  Ipl  terns  Iron  intuit ionistic  proofs. 

extract.sinp  :  I-  A  ->  tern  ->  type. 

XX  Uninfomative  proofs 

exs_n:  extract.sinp  (P:  I-  (not  A))  neg. 

exs.f:  extract.sinp  (P:  I-  false)  (app  neg  unity). 

exs.un:  extract.sinp  (P:  I-  A)  unity  <-  uninf  A. 

XX  COIJUICTIOI 

XX  Don't  build  (pair  M  l:B)  if  B  is  uninfomative. 
exs.andil  :  extract.sinp  (andi  (P:  I-  A)  (Q:  |-  B))  N 
<-  inf  A  <-  extract.sinp  P  M  <-  uninf  B. 


XX  Don't  build  (pair  N:A  I)  if  A  is  uninfomative. 
exs.andi2  :  extract.sinp  (andi  (P:  |-  A)  (Q:  |-  B))  N 
<-  uninf  A  <-  inf  B  <-  extract.sinp  Q  M. 

exs.andiS  :  extract.sinp  (andi  (P:  I-  A)  (Q:  |-  B))  (pair  N  I) 
<-  inf  A  <-  extract.sinp  P  M 
<-  inf  B  <-  extract.sinp  Q  I. 


XX  Don't  build  (fst  M:(*  A  B))  if  B  is  uninfomative. 
exs.andell  :  extract.sinp  (andel  (P  :  I-  (and  A  B)))  N 
<-  inf  A  <-  uninf  B  <-  extract.sinp  P  M. 


exs.andel2  :  extract.sinp  (andel  (P  :  I-  (and  A  B)))  (fst  N) 
<-  inf  A  <-  inf  B 
<-  extract.sinp  P  M. 


XX  Don’t  build  (snd  N:(*  A  B))  if  A  is  uninfomative. 
exs.anderl  :  extract.sinp  (ander  (P  :  I-  (and  A  B)))  M 
<-  uninf  A  <-  inf  B  <-  extract.sinp  P  M. 


exs.ander2  :  extract.sinp  (ander  (P  :  I-  (and  A  B)))  (snd  N) 
<-  inf  A  <-  inf  B 
<-  extract.sinp  P  M. 


XX  DISJUICTIOI 

exs.oril  :  extract  '.np  (oril  B  P)  (ini  H) 

<-  extra*  ,.,inp  P  M. 

exs.orir  :  extract.sinp  (orir  A  P)  (inr  H) 

<-  extract.sinp  P  M. 

exs.ore  :  extract.sinp  (ore  PI  P2  Q)  (decide  N  VI  Hr) 

<-  extract.sinp  Q  M 

<-  (•CP:I~  a}  {p:tem}  extract.sinp  P  p  ->  extract.sinp  (PI  P)  (HI  p)) 
<-  ({P:l-  B}  {pitem}  extract.sinp  P  p  ->  extract.sinp  (P2  P)  (Hr  p)). 
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y.X  INPLICATIOI 

XX  Don't  build  (lam  N)  il  A  is  uninioxmative. 
ezs.implil  :  extract.simp  (impliasi  (P:  I-  A  ->  I-  B))  N 
<-  uninl  A  <-  ini  B 
<-  -Cp:  I-  A}  eztract.simp  (P  p)  M. 

ez8_iapli2  :  extract.simp  (impliasi  (P:  I-  A  ->  I-  B))  (lam  N) 

<-  ini  A  <-  ini  B 

<-  -(Q:  I-  A}  -Cqrtarm}  (axtract.simp  Q  q  ->  axtract.simp  (P  Q)  (M  q)). 

XX  Don’t  build  (app  N  I:A)  il  A  is  uninlormativa. 
axs.implal  :  axtract.simp  (impliasa  (P:  I-  (implias  A  B))  Q)  M 
<-  uninl  A  <-  ini  B  <-  axtract.simp  P  M. 

8xs_impla2  :  axtract.simp  (impliasa  (P:  I-  (implias  A  B))  Q)  (app  M  I) 

<-  ini  A  <-  ini  B 

<-  axtract.simp  P  M  <-  axtract.simp  Q  I. 


XX  IE6ATI0I 

XX  (noti  P)  Bill  alsays  ba  caught  by  tha  rula  "axs.n”  sinca  tha  conclusion  is  "(not  A)". 
XX  (nota  P)  Bill  alBays  ba  caught  by  tha  rula  "axs.l"  sinca  tha  conclusion  is  "lalsa". 

XX  ABSURDITY 

axs.lalsaa  :  axtract.simp  (lalsaa  C  P)  (any  N) 

<-  axtract.simp  P  M. 

XXX  ASSERTIOM 

axs.isay  :  axtract.simp  (isay  A)  unity. 

XXX  Extraction  Bith  ramoval  ol  uninlormativa  parts. 

XXX  Raquiras  pap/axtract-simp.all 

XXX  DYIAMIC 

XX  UIIVERSAL  qUAITIFICATIOH 

axs.lorsaii  :  axtract.simp  ((loralli  P):|-  (lorall  A))  (lam  M) 

<-  ini  (lor2Ql  A) 

<-  {X:i}  {x:tarm>  (axtract.tm  X  x  ->  extract.simp  (P  X)  (M  x)). 

exs.loralle  :  extract.simp  (loralle  T  (P:  I-  (loreQl  A)))  (app  M  H) 

<-  ini  (lorall  A) 

<-  axtract.simp  P  M  <-  axtract.tm  T  I. 

XX  EXISTEITIAL  QUAITIFICATIOI 

XX  Don’t  build  (pair  M  N:A)  il  A  is  uninlormativa. 
exs.existsil  :  extract.simp  (existsi  A  T  .)  M 

<-  ({xci}  uninl  (A  x))  <-  axtract.tm  T  M. 
exs.existsi2  :  axtract.simp  (existsi  ATP)  (pair  M  H) 

<-  ({x:i}  ini  (A  x)) 

<-  axtract.tm  T  M  <-  extract.simp  P  I. 


%%  Va  don't  have  (pair  N  l:A)  if  A  is  uninlomativa. 

exs.axistsal  :  extract.simp  (axistse  P  (Q:  I-  (exists  A))}  (app  (Ian  N)  1) 
<-  ({X:i}  uninf  (A  X)) 

<-  «X:i}  <x:tarm}  extract_t*  X  x 

->  {p:  I-  (A  X)}  axtract.sinp  (P  X  p)  (M  x)) 

<-  axtract.simp  Q  I. 

axs_axistsa2  :  extract.simp  (existsa  P.min  P.naj)  (spread  I  N) 

<-  (tt:i}  inX  (A  X)) 

<-  ({X:i}  •(x:ter»}  extract _tB  X  x 

->  {P:!-  (A  X)}  {p;term>  extract.simp  P  p 
->  extract.simp  (P.min  X  P)  (M  x  p)) 

<-  extract.simp  P.maj  I. 

n  IIDUCTIQ* 

exs.ind  :  extract.simp  (ind  A  Pz  Ps)  (nat.ind  Iz  Is) 

<-  ({X>  ini  (A  X)) 

<-  extract.simp  Pz  Iz 

<-  •{X:i}  {x:term}  extract .tm  X  x 

->  {P:|-  (A  X)>  {p:term>  extract.simp  P  p 
->  extract.simp  (Ps  X  P)  (Is  x  p) . 


*/«%%  Extract  simplified  type 
y.*/,'/.  Dynamic. 

ex.tp.s  :  o  ->  tp  ->  type, 
exts.h:  ex.tp.s  A  unit  <-  uninf  A. 

exts.n:  ex.tp.s  (not  A)  (arrow  T  void)  <-  ex.tp.s  A  T. 
exts.false  :  ex.tp.s  false  void. 

exts.andl  :  ex.tp.s  (and  A  B)  T 

<-  inf  A  <-  ex.tp.s  A  T 
<-  uninf  B. 

exts.andr  :  ex.tp.s  (and  A  B)  T 
<-  uninf  A 

<-  inf  B  <-  ex.tp.s  B  T. 
exts.and  :  ex.tp.s  (and  A  B)  (♦  T1  T2) 

<-  inf  A  <-  ex.tp.s  A  T1 
<-  inf  B  <-  ex.tp.s  B  T2. 

exts.or  :  ex.tp.s  (or  A  B)  (I  T1  T2) 

<-  ex.tp.s  A  T1 
<-  ex.tp.s  B  T2. 

exts.impr  :  ex.tp.s  (implies  A  B)  T 
<-  uninf  A 

<-  inf  B  <-  ex.tp.s  B  T. 
exts.imp  :  ex.tp.s  (implies  A  B)  (eurrow  T1  T2) 
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<-  inf  A  <-  ex_tp_s  A  T1 
<-  inf  B  <-  ex_tp_8  B  T2. 

exts.all  :  ex.tp.s  (forall  A)  (arros  nat  T) 

<-  ({x:i}  inf  (A  x))  <-  {xiO  ax_tp_s  (Ax)  T. 

exts.axl  :  ex.tp.s  (exists  A)  nat 
<-  ({x:i}  nninf  (A  x)). 

exts.ex  :  ex_tp_s  (exists  A)  (*  nat  T) 

<-  ({x:i>  inf  (A  x)) 

<-  ({x:i}  ex_tp_8  (A  x)  T) . 


Appendix  B 

Adequacy  of  encodings 


This  appendix  discusses  the  faithfulness  of  the  encodings  of  the  object  languages  and  inference 
systems  of  Chapter  2.  Following  Harper  et  al.  [HHP93],  we  describe  minimal  correctness  properties, 
called  adequacy  theorems,  for  the  encodings.  Proofs  of  adequacy  tend  to  be  rather  stereotyped  and 
filled  with  unenlightening  detail,  so  we  omit  them. 

Adequacy  in  general  consists  of  two  properties:  the  existence  of  a  bijective  representation  func¬ 
tion  from  the  expressions  of  a  language  to  be  represented  to  terms  of  the  formalized  representation, 
and  the  compositionality  q(  the  representation  function.  The  bijection  ensures  that  every  language 
expression  has  a  unique  representation  as  a  canonical  term  of  the  representing  type,  and  that  every 
such  canonical  term  represents  a  language  expression.  Loosely  speaking,  a  representation  function 
is  compositional  when  it  commutes  with  substitution.  Thus  to  state  an  adequacy  theorem  in  full 
it  is  necessary  to  define  a  representation  function,  possibly  parameterized  to  a  set  of  variables  if 
open  terms  must  be  treated,  and  to  define  substitution  in  both  the  language  to  be  represented  and 
the  representing  formalism.  The  key  idea  in  such  theorems  is  to  identify  the  variables  of  the  repre¬ 
sented  language  with  the  variables  of  the  formalism.  This  identification  reflects  the  basic  principle 
of  representations  based  on  higher-order  abstract  syntax. 

The  encodings  of  first-order  logic  and  natural  deduction  we  used  closely  follow  those  of  Harper 
et  al.  Although  their  encoding  is  for  classical  logic,  this  does  not  materially  affect  the  statements 
and  proofs  of  correctness  (the  major  change  is  to  omit  the  classical  absurdity  rule  from  the  natural 
deduction  inference  system).  Rather  than  restate  the  adequacy  theorems  for  these  we  refer  the 
interested  reader  to  [HHP93]. 

We  assume  as  background  the  definition  of  canonical  forms  for  LF  terms  and  the  proof  of  their 
existence. 


B.l  Adequacy  for  syntax  of  program  expressions  and  types 


Adequacy  for  the  functional  programming  language  and  its  type  system  is  easy  to  state.  We  omit 
the  definition  of  substitution  as  it  is  the  usual  one.  The  definitions  of  representation  functions 
use  typewriter  font  for  LF/Elf  term  constructors  (e.g.,  pair).  An  expression  of  the  form  Xx .  e 
represents  an  LF /Elf  term  of  functional  type. 
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We  repeat  the  syntax  of  the  function  programming  language  used  for  extraction: 


e 


0  I  s(e)  I 

{€1,62)  I  fst(e)  1  snd(e)  |  spread(ei;  a:, y . 62) 
inl(c)  I  inr(e)  |  decide(ei;  x  .62;  a: .  ea)  | 
lamx.e  |  natJnd(ei;  x,y.e2)  |  app(ei,e2)  | 

0  I 

any(e)  j  neg 
axiom 


Variables 
Natural  numbers 
Pairs 

Disjoint  union 
Functions 
Unity 
Error 

Self-realizors 


The  Elf  signature  for  the  representation  of  programming  language  expressions  and  types,  which 
we  denote  by  Ep/,: 

tp  :  type, 
term  :  type. 


arrow  :  tp  ->  tp  ->  tp. 

app  :  term  ->  term  ->  term, 
lam  :  (term  ->  term)  ->  term. 


vmit  :  tp. 
imity  :  term. 

nat  :  tp . 

0  :  term, 
s  :  term  ->  term. 

nat.ind  :  term  ->  (term  ->  term  ->  term)  ->  term. 


*  :  tp  ->  tp  ->  tp. 

pair  :  term  ->  term  ->  term. 

fst  :  term  ->  term. 

snd  :  term  ->  term. 

spread  :  term  ->  (term  ->  term  ->  term)  ->  term. 

I  :  tp  ->  tp  ->  tp. 
ini  :  term  ->  term, 

inr  :  term  ->  term. 

decide  :  term  ->  (term  ->  term)  ->  (term  ->  term)  ->  term. 

void  :  tp. 

any  :  term  ->  term. 

neg  :  term. 


atom  :  tp. 
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axiom  :  tern. 


Definition  B.l  Given  a  set  of  variables  X  =  { , . . . ,  a:„  },  we  define  the  corresponding  Elf  context 
Fx  as  {a;i  :  term, . . .  ,x„  :  term}. 

Definition  B.2  Let  X  be  a  set  of  variables.  The  following  defines  the  representation  function  ex 

for  programming  language  expressions.  The  notation  ex,xx . i„  denotes  the  representation  function 

for  the  set  X  extended  by  the  addition  of  the  variables  Xi,. . .  ,x„. 

£x(a:)  =  x,  if  X  eX 
ex{0)  =  0 
£x(s(e))  =  s  £x{e) 

£x{{  Cl, €2  »  =  pair  fx(ci)  Cx(c2) 

£x(fet(e))  =  fst  £x(c) 

£x(snd(e))  =  snd  £x(c) 

£x(spread(ei;  x, y  .62))  =  spread  £x(ei)  (Ax  :  term.  Ay  :  term.£x,x,v(c2)) 

£x(inl(c))  =  ini  £x(e) 

£x(inr(e))  =  inr  £x(e) 

£x(decide(ei;  x.e2;  x  .63))  =  decide  £x(ei)  (Ax  :  term.£x,x(c2))  (-^^r  :  term.£x,i(e3)) 
£x(lamx.e)  =  lam  Ax  :  term.£x,x(c) 

£x(nat Jnd(ei;  x,y.e2))  =  nat-ind  £x(ci)  Ax  ;  term. Ay  :  term. £x,x,y(c2) 

£x(app(ci,e2))  =  app  fx(ei)  sxie^) 

£x(())  =  unity 
^x(any(e))  =  any  £x(e) 

£x(neg) =  neg 
£x  (axiom)  =  axiom 

Theorem  B.3  Adequacy  for  programming  language  syntax:  For  any  set  of  variables  X,  ex  is 
a  bijection  between  the  expressions  of  the  programming  language  with  free  variables  in  X  and  the 
canonical  forms  of  type  term  in  the  signature  "Lpi,  and  the  context  Fx-  The  encoding  is  com¬ 
positional,  i.e.,  for  a  program  expression  e  with  free  variables  in  X  =  {xi,...,Xn}  and  program 
expressions  ei, . . . , e„  with  free  variables  in  Y, 

fydci/xi, . . .  ,e„/x„]e)  =  [£y(ei)/xi, . . .  ,£y(e„)/x„]£x(e) 

Adequacy  for  programming  language  types  is  simpler  to  state  since  there  are  no  type  variables. 
The  obvious  definition  of  the  representation  function  £  for  types  can  be  made  without  reference  to 
a  set  of  variables  -  £(ri  x  T2)  =  *  £(ri)  £(r2),  etc.  Compositionality  does  not  apply,  so  adequacy 
amounts  to: 

Theorem  B.4  Adequacy  for  programming  language  types:  e  is  a  bijection  between  the  type  ex¬ 
pressions  of  the  programming  language  and  the  canonical  forms  of  type  tp  in  the  signature  UpL. 


B.2  Adequacy  for  programming  language  semantics 

The  correctness  properties  for  evaluation  and  type  assignment  deductions  can  be  stated  in  much  the 
same  way.  Evaluation  is  particularly  simple  since  only  closed  programming  language  expressions 
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occur  in  evaluation  deductions,  and  these  deductions  do  not  introduce  any  assumptions.  Thus 
there  is  no  notion  of  substitution  for  an  evaluation  deduction,  and  an  adequacy  theorem  can  be 
formulated  as  for  the  representation  of  programming  language  types. 

Type  assignment  deductions  introduce  assumptions;  thus  to  state  adequacy  it  is  necessary  (again 
following  Harper  et  al.)  to  slightly  reformulate  the  system  to  be  represented  so  that  assumptions 
are  labelled  by  variables.  Then  the  substitution  of  a  type  assignment  deduction  T  ::  A'  h  e  6  r  for 
an  assumption  variable  ^  x  £  t  can  be  defined  so  that  substitution  preserves  the  validity  of  de¬ 
ductions.  This  entails  simultaneously  substituting  x  for  e  in  the  programming  language  expressions 
of  the  deduction,  as  well  as  combining  sets  of  typing  assumptions.  The  representation  function 
e  is  then  defined  in  terms  of  the  representation  functions  for  programming  language  expressions 
and  types.  Since  representation  of  programming  language  expressions  is  parameterized  by  a  set  of 
programming  language  variables,  we  define: 

Definition  B.5  Given  a  set  of  typing  assumptions  X  =  ::  x\  €  Ti,...,^„  ::  Xn  6  r„},  the 

projection  to  programming  language  variables  p{X)  is 

Figure  2.11  shows  the  Elf  signature  that  represents  the  type  assignment  system  of  Figure  2.10. 
However,  this  form  of  the  signature  exploits  the  Elf  term  and  type  reconstruction  facility  to  avoid 
showing  implicit  arguments  that  must  be  made  explicit  in  order  to  formulate  statements  of  ade¬ 
quacy.  In  practice  these  arguments  are  supplied  by  Elf;  we  show  a  full  declaration  for  the  type 
inference  rule  for  A-abstraction  as  an  example: 

tp_lam  ;  {H;  term  ->  term}  {A;  tp}  {B:  tp} 
of  (lam  M)  (arrow  A  B) 

<-  {x:term}  of  x  A  ->  of  (H  x)  B. 


Here  the  argument  M  of  the  constant  lam,  and  the  types  A  and  B  are  made  explicit.  The  arguments 
of  all  other  constants  in  the  signature  can  be  similarly  treated.  With  the  signature  T,pi  that  defines 
the  syntax,  let  the  resulting  signature  be  Ej-p-  The  representation  function  can  then  be  defined  in 
terms  of  Ejp.  We  show  the  definition  for  functional  abstraction  as  an  example: 

(  ^ 

£  A,  a;  G  Ti  h  e  e  r2 

^X  I-  lam  X  .e  £  Ti  ^  T2 

tp_lam  (Ai  :  term. £p(x),x(e))  £(ti)  £(t'2)  (Ai :  term.  A^  :  of  a;  £(7-1)  .£(T)) 

Definition  B.6  Given  a  set  of  typing  assumptions  X  =  {^1  ::  ii  G  ri,...,^„  ::  a:„  G  r„},  we 
define  the  corresponding  Elf  context  Fx  as  {ii  :  term,  ...,a:„  :  term,^i  :  of  xi  £(ri), . . .  ,^i  : 
of  x„  £(r„)}. 

Theorem  B.7  Adequacy  for  type  assignment  deductions:  £  is  a  bijection  between  the  typing  de¬ 
ductions  T  ::  X  e  £  T  and  the  canonical  forms  of  type  of  ep(A')(c)  signature  Syp  and 

the  context  Fx-  The  encoding  is  compositional,  i.e.,  for  a  typing  deduction  T  ::  X  \-  e  £  t  where 
X  =  { 6  ::  Ii  G  Ti , . . . , x„  G  r„  }  and  typing  deductions  Ti  ::  X'  h  ei  £  rj , . . . ,  ::  A'  h  e„  G 

Tn 


tp-lam 


£([ri/6, .  .  .  ,T„/^n]r)  =  [£(Ti)/6,  .  .  .  ,£(T„)/^„]£(T) 
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Although  there 
deductions  can  be 


are  more  details  to  be  handled,  adequacy  for  extraction  and  extraction/simplification 
stated  similarly. 


Appendix  C 

An  Elf  program  to  recognize 
tail-recursive  form 


The  following  program  encodes  a  deductive  system  for  establishing  whether  a  program  is  in  tail- 
recursive  form.  The  key  idea  of  the  deduction  is  to  check  whether  a  given  bound  variable  occurs 
free  in  certain  subterms  of  a  recursive  definition.  There  are  three  judgments  of  the  system.  The 
judgment  tl_rec_pgm  holds  if  a  program  expression  is  tail-recursive  as  a  whole.  The  judgment 
tl_rec_def  holds  if  a  primitive  recursive  function  definition  is  tail-recursive.  Finally,  tl.rec.body 
is  defined  on  functions  from  program  terms  to  program  terms,  and  does  the  real  work  of  checking 
that  the  bound  variable  represented  by  the  function  parameter  occurs  only  in  legal  positions.  Note 
that  there  are  two  rules  for  the  case  where  the  construct  app  (lam  M)  N  occurs.  This  corresponds 
to  a  let-binding,  where  the  function  parameter  of  interest  must  be  restricted  to  occur  in  the  binder 
or  in  the  body,  but  not  both. 

tl_rec_pgm  :  term  ->  type. 
tl_rec_def  :  term  ->  type. 
tl_rec_body  ;  (term  ->  term)  ->  type. 

trbody_id  :  tl_rec_body  ([x]  x). 
trbody_app  :  tl_rec_body  ([x]  app  (M  x)  ■) 

<-  tl_rec_body  M. 

trbody_app_laml  :  tl_rec_body  ([x]  app  (lam  M)  (I  x)) 

<-  tl_rec_body  ([x]  M  (■  x)). 
trbody_app_lam2  :  tl_rec_body  ([x]  app  (lam  (M  x))  H) 

<-  tl_rec_body  ([x]  M  x  H) . 
trbody.lam  :  tl_rec_body  ([x]  lam  [y]  M  x  y) 

<-  (•Cyl  tl_rec_body  ( [x]  M  x  y) ) . 
trbody_case  :  tl_rec_body  ([x]  decide  M  (II  x)  (Ft  x)) 

<-  (fyl  tl_rec_body  ([x]  HI  x  y)) 

<-  ({yl  tl_rec_body  ([x]  Hr  x  y)). 
trbody_il  :  tl_rec_body  ([x]  if  M  (10  x)  (Hi  x)) 

<-  tl_rec_body  ([x]  10  x) 

<-  tl_rec_body  ([x]  Ml  x) . 

trdel_nat_ind  :  tl_rec_del  (nat_ind  Mb  Ms) 
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<-  tl_rec_pgB  Mb 

<-  ({x}  tl_rec_body  ([y]  Ns  x  y)). 
trdsi_li8t_ind  :  tl_r«c_def  (list.ind  Mnil  Neons) 
<-  tl_rec_pgm  Mnil 

<-  {{1>  <x}  tl_r6c_body  ([y]  Neons  1  y  x)). 

trpgB_nat_ind  :  tl_ree_pgm  (nat.ind  Mb  Ns) 

<-  tl_rec_dei  (nat.ind  Mb  Ns) . 
trpgm_list_ind  :  tl.ree.pgm  (list.ind  Mnil  Neons) 
<-  tl.rec.dsf  (list.ind  Mnil  Neons). 
trpgm_app  :  tl_ree_pgm  (app  Ml) 

<-  tl_ree_pgm  M 
<-  tl_rae_pgm  I. 
trpgm.lan  :  tl.rse.pgn  (lam  N) 

<-  ({x}  tl_rse_pgm  x  ->  tl_rae_pgm  (M  x)). 
trpgm_unity  :  tl_rsc_pgm  unity. 
trpgm_0  ;  tl_ree_pgm  0. 
trpgm_s  :  tl_rse_pgm  (s  M) 

<-  tl_rae_pgm  M. 

trpgm_pr  :  tl_ree_pgm  (pair  Ml) 

<-  tl_rsc_pgm  N 
<-  tl_rec_pgm  I. 
trpgm_lst  :  tl_ree_pgm  (fst  N) 

<-  tl_rsc_pgm  M. 
trpgm.snd  :  tl_rae_pgm  (snd  M) 

<-  tl_rac_pgm  M. 

trpgm_8pr6ad  :  tl_r6c_pgm  (spread  M  I) 

<-  tl_ree_pgm  M 

<-  ({x}  -Cy}  tl_ree_pgm  x  ->  tl_ree_pgm  y 
->  tl_ree_pgm  (I  x  y)). 
trpgm_inl  :  tl_ree_pgm  (ini  N) 

<-  tl_reo_pgm  N. 
trpgm_inr  :  tl_reo_pgm  (inr  N) 

<-  tl_rec_pgm  M. 

trpgm.deeide  :  tl_ree_pgm  (deeide  N  II  Ir) 

<-  tl_ree_pgm  N 

<-  ({x>  tl_ree_pgm  x  ->  tl_rec_pgm  (II  x)) 
<-  ({x>  tl.ree.pgm  x  ->  tl_ree_pgm  (Ir  x)). 
trpgm_any  :  tl_ree_pgm  (any  N) 

<-  tl_roe_pgm  N. 
trpgm_neg  :  tl_reo_pgm  neg. 

trpgm_ease_nat  :  tl_reo_pgm  (ease.nat  M  10  Is) 

<-  tl_ree_pgm  M 
<-  tl_reo_pgm  10 

<-  {x}  tl_reo_pgm  x  ->  tl_rec_pgm  (Is  x) . 
trpgm_pred  :  tl_ree_pgm  (pred  M) 

<-  tl_rec_pgm  M. 

trpgm_minns  :  tl_ree_pgm  (M  -  1) 

<-  tl.’  ^o_pgm  N 
<-  tl 

trpgm.plUL  tl_iee_pgm  (M  +  I) 
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<-  tl.rec.pga  M 
<-  tl_rec_pgB  I. 

trpgB_iaul  :  tl_rec_p^  (buI  K  I) 

<-  tl.rec.pgB  M 
<-  tl_r«c_pgB  I. 

trpgB.8ign  :  tl_rec_pgB  (signua  N) 

<-  tl_r«c_pgB  M. 
trpgB_eq  :  tl_r«c_pgm  (H  =  I) 

<-  tl_r«c_pgB  M 
<-  tl.rec.pgB  I. 

trpgB_il  :  tl_r*c_pgB  (if  M  It  If) 

<-  tl_rac_pgB  M 
<-  tl_r®c_pgB  It 
<-  tl_r«c_pgB  If. 
trpga_ga  :  tl_rac_pgB  (M  >=  I) 

<-  tl.rac.pgB  M 
<-  tl_rac_pgB  I. 
trpgB_aq?  :  tl.rac.pga  (=?  M  I) 

<-  tl.rac.pga  M 
<-  tl_rac_pgB  1. 
trpgB_nil  :  tl_rac_pgBi  nil. 
tzpgB_con8  ;  tl.rac.pgm  (cona  Ml) 

<-  tl_rac_pgm  M 
<-  tl_rac_pgiB  I. 

trpgB.ca.8a_li8t  :  tl.rac.pgn  (casa.list  M  Inil  Icons) 
<-  tl_rac_pgm  M 
<-  tl_rac_pgm  Inil 

<-  <x>  tl_rac_pgm  x  ->  <1}  tl.rac.pgn  1 
->  tl.rac.pgn  (Icons  x  1) . 
trpgn.«  :  tl.rac.pgn  (C  N  I) 

<-  tl_rac.pgn  M 
<-  tl.rac.pgn  I. 


Using  the  techniques  of  Chapter  3,  we  partially  encoded  a  proof  that  the  tail-recursion  intro¬ 
duction  transformation  of  Chapter  4  yields  a  tiul- recursive  program  if  it  succeeds. 

Theorem  C.l  Any  program  extracted  from  the  output  proof  constructed  by  a  successful  application 
of  tail-recursion  introduction  is  tail-recursive. 

The  theorem  is  represented  by  the  declaration: 
tl.rec.pf  : 

tail.rec.doubleneg  .....  Phi  Psi 
Input .proof  II  12  13 
Output .proof  -> 

eztract.simp  Output .proof  Prog  ->  tl.rec.pgm  Prog  ->  type. 
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The  proof  relies  on  “inversion”;  since  the  transformation  is  defined  by  a  single  clause,  the  form 
of  the  output  proof  can  be  read  off  from  that  clause.  This  in  turn  determines  the  form  of  the 
extraction  deduction,  thus  of  the  extracted  program,  in  enough  detail  that  the  required  deduction 
of  tail-recursiveness  can  be  constructed.  The  representation  of  the  proof  is  incomplete  because  we 
have  assumed  without  proof  that  any  program  expression  extracted  from  an  individual  term  of  the 
logic  is  tail-recursive.  This  is  not  hard  to  prove  although  the  details  are  tedious.  The  following 
clause  represents  the  partial  proof: 

tr_pf  : 

{RO}  {S0>  {MSO}  {ESO  :  {k>  fk’}  «xtract_l_tm  k  k’  ->  extract_l_t«  (SO  k)  (MSO  k’)} 

{KO}  fMKO}  {EKO  :  extract.l.tm  KO  MKO} 

<F} 

{H>  <IQi> 

■CEH  :  fx}  {xO  extract.tm  x  x’  ->  fk}  fk’}  extract.l.tm  k  k’  ->  extract_l_tm  (H  x  k)  (Mh  x’  k’)} 
{Phi>  {Psi>  {Db>  {11}  {12}  {13} 

{Ds}  {Inbase}  {Instep}  {leone}  {Ine.ded}  {Ins.ded}  {Inb.ded} 

{base.tzpl  :  {k}  tl_ree_pgn  k  ->  tl_ree_pgB  (MSO  k)} 

{init_trpf  ;  tl_ree_pgn  MKO} 
tl_ree_pl 

(tl.ree.doubleneg  RO  SO  KO  F  H  Phi  Psi  Db  II  12  13 
Ds  Inbase  Instep  leone 
Ine.ded  Ins.ded  Inb.ded) 

y.  Extraetion  deduetion  Bust  have  the  follouing  form: 

(exs.lloxalli 

([11]  [11*]  [ell:  extraet.l.tm  11  11*] 
exs.lexistsel 
(exs.lforalle  EKO 
(exs.ltoralle  ell 

(exs.lind  ([1]  [1*]  [el:  extraet.l.tm  11’] 

[p]  [p*]  [ep:  extraet.simp  p  p’] 

[x]  [x*]  [ex:  extraet.tm  x  x'] 
exs.lforalli  ([k]  [k*]  [ek:  extraet.l.tm  k  k’] 
exs.lexistsel  (exs.lforalle  (EH  x  x’  ex  k  k’  ek)  ep  (inf.lforall  [k]  inf.lexists) ) 

([s]  [s’]  [es:  extraet.l.tm  s  s’] 

[hyp]  [ehyp:  extraet.simp  hyp  unity] 
exs.lexistsil  es  ([x]  unin.n)) 

([1]  unin.n)) 

(inf.lforall  [1]  inf.lexists)) 

(exs.lforalli 

([k]  [k’]  [ek:  extraet.l.tm  k  k’]  exs.lexistsil  (ESO  k  k’  ek)  ([x]  unin.n)) 

(inf.lforall  [1]  inf.lexists)) 

([1]  inf.lforall  [1]  inf.lexists)) 

(inf.lforall  [1]  inf.lforall  [k]  inf.lexists)) 

(inf.lforall  [k]  inf.lexists)) 

([s]  [s’]  [es:  extraet.l.tm  s  s’]  [p]  [ep:  extraet.simp  p  unity] 
exs.lexistsil  es  ([s]  unin.n)) 

([l:ilist]  unin.n)) 

(inf.lforall  ([1]  inf.lexists))) 

Deduetion  that  extraeted  program  is  tail-reeursive: 

(trpgm.lam 
([1]  [trl] 
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trpgB_app 

(trpgB_app 

init.trpl 

(tTpgB_app 

trl 

(trpgB_list.ind 

(trdaf_list_ind 

([1]  Cx]  trbody_la«  ([y]  trbody.app.laal  (trbody.app  trbody.id))) 
(trpgB.laB  Ck]  [trk]  base.trpl  k  trk)  )))) 

(trpgm_laB  ([x]  [trx]  trx))))  . 


Appendix  D 

Extensions  of  Elf  encoding  to 
many- sorted  logic  for  Chapter  4 


D.l  Extended  arithmetic 


'/,y.  Interpret  "i"  of  FOL  as  natural  numbers 

zero  :  i. 
succ  :  i  ->  i. 

Equality 

eq  :  i  ->  i  ->  o. 

ax_zero  :  {X:i>  I-  (not  (eq  (succ  X)  zero)). 
eq_refl  :  {T:i>  |-  (eq  T  T) . 

eq_repl  ;  {A-.i  ->  o}  1-  (A  T)  ->  1-  (eq  T  T')  ->  1-  (A  T’). 

'/,  Induction 

ind  :  {A:i  ->  o}  I-  (A  zero)  ->  (•(x:i}  |-  (A  x)  ->  I-  (A  (succ  x))) 
->  1-  (forall  A). 

predecessor,  subtraction,  addition,  multiplication 
prd  :  i  ->  i. 

prdz  :  I-  (eq  (prd  zero)  zero), 
prds  ;  {T}  I-  (eq  (prd  (succ  T))  T) . 

sb  :  i  ->  i  ->  i. 

sbz  :  {T}  I-  (eq  (sb  T  zero)  T) . 

sbs  :  {Tl>  m}  I-  (eq  (sb  T1  (succ  T2))  (prd  (sb  T1  T2))). 
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ad  :  i  ->  i  ->  i. 

adJ8  :  {T>  I-  (aq  (ad  T  zero)  T) . 

ads  :  -CTl}  {T2}  I-  (eq  (ad  T1  (succ  T2))  (succ  (ad  T1  T2))). 

■1  :  i  ->  i  ->  i. 

mlz  ;  <T}  I-  (eq  (ml  T  zero)  zero). 

mis  :  {Tl}  {T2>|-  (eq  (ml  T1  (succ  T2))  (ad  (ml  T1  T2)  TD). 

%%  "Boolean"  functions  (zero  codes  truth,  (succ  zero)  codes  falsehood) 
sg  :  i  ->  i.  •/.  (sg  x)  =  0  iff  X  =  0,  (sg  x)  <=  1  for  all  x 

sgx  :  {T}  I-  (eq  (sg  T)  (sb  (succ  zero)  (sb  (succ  zero)  T))). 

*/,  equality  test 
eq?  :  i  ->  i  ->  i. 

eq?x  :  {Tl}  {T2>  I-  (eq  (eq?  Tl  T2)  (sg  (ad  (sb  Tl  T2)  (sb  T2  Tl)))). 

*/•  conditionals 

suitch  :  i  ->  i  ->  i  ->  i. 

switchz  :  {Tl}  {T2}  I-  (eq  (suitch  zero  Tl  T2)  Tl). 
szitchs  :  {Tl}  {T2}  I-  (eq  (snitch  (succ  zero)  Tl  T2)  T2) . 

V,  inequalities 

ge?  :  i  ->  i  ->  i.  X  greater  than  or  equal 

ge?x  :  {Tl}  {T2}  I-  (eq  (ge?  Tl  T2)  (sg  (sb  T2  Tl))). 

XXX  Extraction  zith  removal,  of  uninformative  parts. 
yX/>  For  primitive  recursive  arithmetic  rules  of  proof. 

%%•/.  DYIAMIC 

7,*/.  Equality 

X  Peq  proves  (eq  Tl  T2)  thus  has  no  computational  content. 
exs_eq_repl  :  extract.simp  (eq_repl  A  Pa  Peq)  M 
<-  extract.simp  Pa  M. 

XX  UlIVERSAL  QUAITIFICATIOI 

exs.foralli  :  extract_simp  ((foralli  P):|-  (forall  A))  (lam  M) 

<-  inf  (forall  A) 

<-  {X:i}  {x:term}  (extract_tm  X  x  ->  oxtract_simp  (P  X)  (M  x)). 
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exs.forallfl  :  extract.siap  (loralle  T  (P:  |-  (forall  A)))  (app  M  M) 

<-  ini  (lorall  A) 

<-  extract.sinp  P  M  <-  extract_t*  T  I. 

y.y.  EXISTEITIAL  qUAITIFICATIOl 

y.y.  Don't  build  (pair  N  l:A)  il  A  is  uninformative. 

exs.existsil  :  extract.simp  (existsi  A  T  _)  M 

<-  ({x:i>  uninf  (A  x))  <-  extract_tm  T  M. 

exs_exist8i2  :  extract.simp  (existsi  ATP)  (pair  N  I) 

<-  (■Cx:i>  inf  (A  x)) 

<-  extract.tm  T  M  <-  extract.simp  P  S. 

V/t  We  don’t  have  (pair  N  l:A)  if  A  is  uninformative. 

exs.existsel  :  extract.simp  (existse  P  (Q:  I-  (exists  A)))  (app  (lam  N)  I) 
<-  ({X:i}  uninf  (A  X)) 

<-  ({Xii}  {x:term}  extract.tm  X  x 

->  {p:  I-  (A  X)>  extract.simp  (P  X  p)  (M  x)) 

<-  extract.simp  Q  I. 

exs_existse2  :  extract.simp  (existse  P.min  P.maj)  (spread  K  M) 

<-  (•(X:i}  inf  (A  X)) 

<-  ({X:i}  {x:term}  extract.tm  X  x 

->  {P:|-  (A  X)}  {p:term>  extract.simp  P  p 
->  extract.simp  (P.min  X  P)  (M  x  p)) 

<-  extract.simp  P.maj  I. 

y.y.  IIDUCTIOH 

exs.ind  :  extract.simp  (ind  A  Pz  Ps)  (nat.ind  Hz  Hs) 

<-  (m  inf  (A  X)) 

<-  extract.simp  Pz  Hz 

<-  <X:i>  -Cxiterm}  extract.tm  X  x 

->  {P:l-  (A  X)}  {p:term}  extract.simp  P  p 
->  extract.simp  (Ps  X  P)  (Hs  x  p) . 


D.2  Monomorphic  lists 

*/.*/■'/.  (Logical)  S3rntactic  categories. 

ilist  :  type.  liname  ilist  Ikuvwl'Jc'u'v'H' 

'/t'/t'/.  (Logical)  abstract  syntax. 

IforeG.!  :  (ilist  ->  o)  ->  o. 
lexists  ;  (ilist  ->  o)  ->  o. 

y.y.y.  Lists  lor  FOL 

nl  :  ilist. 

ens  :  i  ->  ilist  ->  ilist. 
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laq  :  ilist  ->  ilist  ->  o. 
l«q_rell  :  xL: ilist}  |-  (leq  L  L). 

leq_rspl  :  {Arilist  ->  o>  |-  (A  L)  ->  I-  (leq  L  L’)  ->  I-  (A  L’). 
leq_nl  :  {X:i}  <L: ilist}  I-  (not  (leq  nl  (cns  I  L))). 

leq_cns  :  I-  (eq  X  Y)  ->  |-  (leq  LI  L2)  ->  I-  (leq  (cns  X  LI)  (cns  Y  L2)). 

%%%  Rules  of  proof  for  quantifiers. 

Iforalli  :  ({x: ilist}  I-  (Ax))  ->  |-  (Iforall  A). 

Iforalle  ;  -[T: ilist}  I-  (Iforall  A)  ->  I-  (A  T). 

lexistsi  :  {A:ilist  ->  o}  ■CT;iliat}  I-  (A  T)  ->  I-  (lexists  A), 
lexistse  :  ({x: ilist}  I-  (Ax)  ->  I-  C)  ->  |-  (lexists  A)  ->  1-  C. 

lind  :  {A: ilist  ->  o}  I-  (A  nl) 

->  ({1: ilist}  I-  (A  1)  ->  -Cxti}  |-  (A  (cns  x  1))) 

->  I-  (Iforall  A). 


elem  :  i  ->  ilist  ->  o. 

eleiB_nil  :  {X}  I-  (not  (elem  X  nl)). 

elem_hd  :  «}  {L}  I-  (elem  X  (cns  XL)). 

elem_tail  :  {Y}  I-  (elem  X  L)  ->  1-  (elem  X  (cns  Y  L)). 

elem_ind  :  {A:i  ->  o}  {Y}  <X}  {L}  I-  (elem  Y  (cns  X  D) 

->  I-  (A  X) 

->  ({Z}  I-  (elem  Z  L)  ->  I-  (A  Z)) 

->  I-  (A  Y). 

elem_case  :  |-  (not  (eq  X  Y))  ->  |-  (not  (elem  X  L))  ->  I-  (not  (elem  X  (cns  Y  L))). 

elem_decide  :  {X}  {L}  I-  (or  (elem  X  L)  (not  (elem  X  L))). 

append  :  ilist  ->  ilist  ->  ilist. 
append_id_l  :  {L}  I-  (leq  (append  nl  L)  L) . 
append_id_r  :  -{L}  1-  (leq  (append  L  nl)  L). 

append.assoc  :  {X}  {LI}  {L2}  I-  (leq  (append  (cns  X  LI)  L2)  (cns  X  (append  LI  L2))). 

Isvitch  :  i  ->  ilist  ->  ilist  ->  ilist. 

Issitchz  :  {Tl}  {T2}  I-  (leq  (Issitcb  zero  T1  T2)  Tl). 

Isuitchs  :  {Tl}  {T2}  |-  (leq  (Isuitcti  (succ  zero)  Tl  T2)  T2). 


7.y.y. 

V/X  Extraction/simplification 

•m 


h_leq  :  harrop  (leq  L  K) . 
h.elem  :  harrop  (elem  X  L) . 


h.lforall  :  harrop  (Iforall  A)  <-  {x:ilist}  harrop  (A  x). 
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unin.lsq  :  uninl  (leq  L  K) . 
unin.elm  :  uninl  (elea  X  L) . 

uiiiii_lloradl  :  oninl  (Iforall  A)  <-  {x:ilist}  uninl  (A  x). 
inf.lexists  :  ini  (lexists  A). 

inl.lforall  :  ini  (llorall  A)  <-  ■Cx:ili8t>  ini  (A  x). 


extract_l_tm  :  ilist  ->  term  ->  type. 

ex.nil  :  extract.l.tm  nl  nil. 

ex.cons  ;  extract_l_tm  (cna  X  L)  (cons  X’  L’) 

<-  extract _tm  X  X’  <-  extract_l_tm  L  L* . 
ex.append  :  extract  ...tm  (append  LI  L2)  (C  LI*  L2’) 

<-  extract_l_tm  LI  LI’  <-  extract _l_tm  L2  L2’. 
ex.lil  :  extract.l.tm  (Issitch  X  LI  L2)  (il  M  Ml  M2) 

<-  extract_tm  X  M 
<-  extract_l_tm  LI  Ml 
<-  extract_l_tm  L2  M2. 

'HHU  Extraction,  vith  simplilication,  lor  lists  ol  individueds 
•/.•/.*/,  DYIAMIC 
7.*/.  Equality 

'!%  Peq  proves  (leq  T1  T2)  thus  has  no  computational  content. 
exs_leq_repl  :  extract.simp  (leq.repl  A  Pa  Peq)  M 
<-  extract.simp  Pa  M. 


7.7.  Membership 

7t  P.elem  has  no  computational  content 

exs.elem.ind  :  extract.simp  (elera_ind  A  Y  X  L  P_elem  P_hd  P_tl) 

(il  (Y*  =  X’)  II  (Ir  Y’)) 

<-  extract _tm  Y  Y’  <-  extract _tm  X  X’ 

<-  extract_simp  P_hd  II 
<-  ({T>  {t>  extract. tm  T  t 

->  {P}  extract.simp  (P_tl  T  P)  (Ir  t)). 

7.7.  UIIVERSAL  qUAITIFICATIOI 

exs.lloralli  :  extract.simp  ((lloralli  P):|-  (llorall  A))  (lam  M) 

<-  ini  (llorall  A) 

<-  -{L:ilist}  {l:term}  (extract_l_tm  L  1  ->  extract.simp  (P  L)  (M  1)). 

exs.lloralle  :  extract.simp  (lloralle  T  (P:  |-  (llorall  A)))  (app  M  I) 

<-  ini  (llorall  A) 

<-  extract.simp  P  M  <-  extract_l_tm  T  1. 
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•/,•/,  EXISTENTIAL  QUANTIFICATION 

Don't  build  (pair  N  N:A)  iT  A  is  uninformative. 

exs.lexistsil  :  extract.simp  (lexistsi  A  T  .)  H 

<-  ({x:ilist}  uninf  (A  x))  <-  extract_l_tm  T  M. 

exs_lexistsi2  :  extract.simp  (lexistsi  ATP)  (pair  M  N) 

<-  (■Cx:ilist}  inf  (A  x)) 

<-  extract_l_tm  T  M  <-  extract_simp  P  N. 

V,'/.  We  don’t  have  (pair  M  N:A)  if  A  is  uninformative. 

exs_lexistsel  :  extract_simp  (lexistse  P  (Q:  I-  (lexists  A)))  (app  (lam  M)  N) 
<-  ({L:ilist}  uninf  (A  D) 

<-  ({L:ilist}  •(l:terTii}  extract_l_tm  L  1 
->  {p:  I-  (A  L)}  extract_simp  p  unity 
->  extract_simp  (P  L  p)  (M  1)) 

<-  extract.simp  Q  N. 

exs_lexistse2  :  extract_simp  (lexistse  P_min  P_maj)  (spread  N  M) 

<-  (<L:ilist}  inf  (A  L)) 

<-  ({L:ilist>  •(l:term}  extract_l_tm  L  1 

->  {P:|-  (A  L)}  {p:term}  extract_simp  P  p 
->  extract.simp  (P_min  L  P)  (M  1  p)) 

<-  extract.simp  P_maj  H. 

exs_lind  :  extract_simp  (lind  A  Pn  PI)  (list_ind  Nn  Nl) 

<-  ({L>  inf  (A  D) 

<-  extract_simp  Pn  Nn 

<-  ({L:ilist3-  {l:term}  extract_l_tm  L  1 

->  -CP:!-  (a  L)}  {p:term}  extract_simp  P  p 
->  {X:i}  {x:term}  extract_tm  X  x 
->  extract_simp  (PI  L  P  X)  (Nl  1  p  x)). 


D.3  Functional  programming  language 

*/.*/,’/,  Abstract  synteuc  of  terms  and  types, 
y.7.*/.  Static. 

'/,  Extensions  for  nats. 
pred  :  term  ->  term. 

-  :  term  ->  term  ->  term.  '/.infix  left  20  - 

+  :  term  ->  term  ->  term.  '/.infix  left  20  + 

mul  :  term  ->  term  ->  term. 


signuin  :  term  ->  term. 

=  :  term  ->  term  ->  term.  V.inlix  none  10  = 

it  :  term  ->  term  ->  term  ->  term. 

>=  :  term  ->  term  ->  term.  ‘/.infix  none  10  >= 

=?  :  term  ->  term  ->  term. 

'/,  Extensions  for  lists  of  nats. 

list  ;  tp. 
nil  :  term. 

cons  :  term  ->  term  ->  term. 

list_ind  :  term  ->  (term  ->  term  ->  term  ->  term)  ->  term, 
case.list  :  term  ->  term  ->  (term  ->  term  ->  term  )  ->  term. 
•  :  term  ->  term  ->  term. 


Appendix  E 

Elf  encodings  of  extracted  programs 
of  Chapter  4 


This  appendix  gives  the  programs  of  Chapter  4  as  extracted  by  the  implementation.  These  differ 
from  the  ML  versions  not  only  in  syntax  but  in  the  absence  of  let-bindings. 

The  code  extracted  from  Proof  4.2: 
list.ind  nil 

([l:term]  [p:term]  [x:term] 

app  (lam  [ll:term]  if  (x  >=  s  s  0)  (cons  x  11)  11)  p) 


The  code  extracted  from  the  result  of  applying  the  naive  form  of  tail-recursion  introduction: 

lam  [l:term] 
spread 

(app  (app  (list.ind 

(lam  [ll:term] 
pair  11 
(pair  nil 

(app  (lam  [lll:term]  lam  [x:term]  inr  imity)  11))) 

([ll:term]  [p:term]  [x:term]  lam  [lll:term] 
spread  (app  p  (if  (x  >=  s  s  0)  (cons  x  111)  111)) 

([llll:term]  [pl:term] 
spread  pi 

(  [mil  :term]  [pll:term] 
pair  1111 

(pair  (if  (x  >=  s  s  0)  (cons  x  11111)  11111) 

(app  (app  (app 

(app  (app  (lam  [xl:term]  lam  [111111 :term3  lam  [1111111 :term] 
lam  [11111111 :term]  lam  [q:term]  lam  [xll:term] 
decide  (app  q  xll)  ([plll:term]  ini  unity) 
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111) 

11111) 


([plllrterm] 
decide  (if  (xl 
([pllll  :tenn] 
(  [pill  1  .-term] 


>«  s  s  0)  (ini  unity)  (inr  unity)) 
if  (xll  =  xl)  (ini  unity)  (inr  unity)) 
inr  unity))) 


1) 


1111) 

pll)))))) 


nil) 

([llrterm]  [prterm]  spread  p  ([lllrterm]  [plrterm]  11)) 


The  code  extracted  from  the  result  of  applying  the  lifted  form  of  tail-recursion  introduction: 

lam  Clitenn] 
spread 

(app  (app  (list.ind 

(lam  [11: term] 

pair  11  (pair  nil  (lam  [x:term]  inr  unity))) 

([11: term]  [p:term]  [x:term]  lam  [111: term] 
spread  (app  p  (if  (x  >*  s  s  0)  (cons  x  111)  111)) 

([1111: term]  [pi: term] 
spread  pi 

( [mil : term]  [pll: term] 
pair  1111 

(pair  (if  (x  >=  s  s  0)  (cons  x  11111)  11111) 

(lam  [xl:term] 

decide  (app  pll  xl) 

([pill .-term]  ini  unity) 

([pill: term] 
decide 

(if  (x  >=  s  s  0)  (ini  unity) 

(inr  unity)) 

( [pllll :term] 

if  (xl  =  x)  (ini  unity)  (inr  unity)) 

( [pllll :term]  inr  unity)))))))) 

1) 

nil) 

([ll:term]  [p:term]  spread  p  ([lll:term]  [pl:term]  11)) 


The  code  extracted  from  the  result  of  applying  lifted  tail-recursion  introduction  with  double 
negation: 
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lam  [l:term'' 
app  (lam  Cll:term]  11) 

(app  (app  (list.ind  (lam  [11: term]  11) 

([ll:term]  [p:term]  [x:term]  lam  [lllrterm] 
app  (lam  [llll:term]  1111) 

(app  p  (if  (x  >=  s  s  0)  (cons  x  111)  111))))  1) 

nil) 
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